terface.
>
>
> By "bootloader" you mean grub, correct?
Yeah, exactly, the grub menu. On our installer images we use it to
offer various choices (install, run a media check and install, run
rescue mode...)
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
On Tue, 2022-09-27 at 13:34 -0300, Daniel Henrique Barboza wrote:
> Hi Adam,
>
> On 9/26/22 06:26, Gerd Hoffmann wrote:
> > On Sat, Sep 24, 2022 at 12:12:45AM -0700, Adam Williamson wrote:
> > > On Mon, 2022-09-19 at 06:42 +0200, Gerd Hoffmann wrote:
> > > >
This got resolved along the way and wasn't really a qemu bug anyway.
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1762558
Title:
Many
Public bug reported:
There's a documented change in qemu 6.0:
https://qemu-project.gitlab.io/qemu/system/removed-features.html#floppy-
controllers-drive-properties-removed-in-6-0
where you can't configure floppy controller device properties with
-global any more. However, there's a thing you cou
I'm not subscribed there, so will note here: I tried the proposed
changes - the commits from https://lists.gnu.org/archive/html/qemu-
devel/2018-12/msg04819.html , backported to 3.0.0 - and that seems to
work. A test which would previously have hit this bug ran OK, without
the changes to the en-us
solve this problem.
I'll try and find a minute to do a scratch build with this patch (and
without my keymap patch) and throw it on openQA staging, since openQA
seems to do a great job of testing qemu input code. :P
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Indeed the bug does not exist in this exact form any more, but it seems
the stray '86' keymap entry *does* still cause problems in current qemu
in one specific case:
https://bugzilla.redhat.com/show_bug.cgi?id=1658676
basically, if using 'usb-kbd', we still get trouble when openQA (os-
autoinst)
Up to you, of course. Just realized I didn't mention here that I also
reported this downstream, and since it turns out to be not triggered by
a qemu change I've been doing most of the investigation there:
https://bugzilla.redhat.com/show_bug.cgi?id=1565354
So far it's looking like the change that
...on the other hand, I was clearly not thinking straight in associating
this with the qemu version bump in Rawhide, because we don't *run* that
qemu. We use the qemu from the worker host, not from the image under
test, and the worker hosts are not running Rawhide, and their qemu
hasn't changed dur
Nothing about SPICE changed in the affected time frame. This started
happening between 2018-04-02 and 2018-04-07. The last time SPICE was
changed in Rawhide was on 2018-02-09. However, qemu was bumped from rc1
to rc2 on 2018-04-05.
It's possible that https://bugzilla.redhat.com/show_bug.cgi?id=156
Public bug reported:
Since qemu 2.12.0 rc2 - qemu-2.12.0-0.6.rc2.fc29 - landed in Fedora
Rawhide, just about all of our openQA-automated tests of Rawhide guests
which run with qxl / SPICE graphics in the guest have died partway in,
always shortly after the test switches from the installer (an X
en
Public bug reported:
This has been reported and discussed downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1484130
but doesn't seem to be getting a lot of traction there.
Basically, with qemu since at least 2.10, you cannot use a disk image on
an SMB share that's mounted with protocol ve
Note: I wondered if specifying a correct model for qemu-keymap to pass
to xkb would help. But it doesn't :( That is, these:
qemu-keymap -l us
qemu-keymap -l us -m pc101
qemu-keymap -l us -m pc104
qemu-keymap -l us -m pc105
all produce the same output except for the commented-out 'model' line at
t
Confirmed that dropping the offending keycode 86 definition out of
keymaps/en-us fixes the problem. Scratch build for Fedora Rawhide was
https://koji.fedoraproject.org/koji/taskinfo?taskID=23814932 , I'll
probably send this out as an official build so I can get os-autoinst
built without hacking up
FWIW, I think this keycode represents the key between the left shift key
and the first letter key on the fourth row, if there is one. European
keyboards have one, and on e.g. a UK keyboard it types a \ unshifted and
a | shifted - this is exactly how it looks in the en-gb keymap file:
# evdev 86 (0
Aha. This looks like my bug!
I'm running into this in what I suspect is the same situation as Michal
Nowak: openQA. But in Fedora. openQA (well, its test runner, os-
autoinst) works by running virtual machines and interacting with them
over VNC. It seems that with qemu 2.11, typing certain charact
I found something interesting using showkey in the VM. This is all
assuming en-US everywhere, note. On a US keyboard, "<" is a shifted
comma (shift-,), ">" is a shifted period (shift-.), and "|" is a shifted
backslash (shift-\).
If I run showkey and try the affected characters in virt-manager, the
I also confirm Michal's observation of virt-manager and tigervnc
behaving differently with the same VM: I ran a VM set up with VNC
display server in virt-manager and can type < from the virt-manager UI
fine, but if I connect to the same VM with tigervnc and try to type < ,
I get > . This is with cu
I note this block in pc-bios/keymaps/en-us with interest:
# evdev 86 (0x56), QKeyCode "less", number 0x56
less 0x56
greater 0x56 shift
bar 0x56 altgr
brokenbar 0x56 shift altgr
That block was added in commit a7815faffb2bd594b92aa3542d7b799cc89c5414
, which I am very suspicious was the cause of th
Note, os-autoinst is its own VNC client. Most of the implementation can
be found in https://github.com/os-autoinst/os-
autoinst/blob/master/consoles/VNC.pm . The functions relevant to sending
key events are `shift_keys`, `init_x11_keymap`, `map_and_send_key`, and
`_send_key_event`.
--
You receive
20 matches
Mail list logo
