[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]
** Changed in: qemu (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906155
Tit
I really wish I could pinpoint the exact root cause, to be able to feed
it back, help others (i.e. fix it once and for all, for everyone :-)).
So far though, no luck. I'm still digging, I haven't given up!
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Ok, glad to hear that it works now. Were you able to sort out what it
was - read this like: "is there anything we need to consider for a
fix/backport or are we just happy things work and close it"?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
FYI, several updates here - for other reasons, but ... BIOS, Linux
(Ubuntu), qemu (to master) => now it works on boot. Arrgh! I only say
that because I can't duplicate it any more, with all these updates.
That's good overall. LOL!
Thanks!
--
You received this bug notification because you are a m
Sure, will do. Just to make sure, this mailing list I assume?
https://lists.nongnu.org/mailman/listinfo/qemu-devel
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906155
Title:
USB Passthrou
> Hmm, not sure what else to do - or is it just ... live with it?
You still have the option to report it upstream and hope that someone
in the wider community has seen it before.
Especially now that we already checked plenty of corner cases and
special conditions your report should be more substan
Yep, checked the devices (thanks!), and I get,
$ lsusb -v -d 046d:c52b | grep bInterfaceProtocol
bInterfaceProtocol 1 Keyboard
bInterfaceProtocol 2 Mouse
bInterfaceProtocol 0
Pretty much as expected.
Hmm, not sure what else to do - or is it just ... live with it?
> LOL. This really is very odd. I'm open to any thoughts you have.
Thanks!
Indeed - it might come down to the actual USB devices/Hubs in play and
their exact type and firmware.
OTOH that might also explain why not everyone ever using it complains
about it being dysfunctional but a few do.
> Could
OK, this is going to sound crazy, but ...
I did exactly like you note above - and the same thing happens. My USB
device isn't seen / avaiable on start, but after I reset the VM ..
voila! It's there and works.
OK, wondering what else it could be. I have a USB hub where the device
is plugged in - w
BTW, one other interesting thing I just noticed, in lsusb. As this
Logitech receiver connects to multiple devices (e.g. keyboard, mouse), I
see it "3 times",
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__
The following should get you the same test environment I used.
$ qemu-img create /var/lib/libvirt/images/ubuntu20.04-UEFI.qcow2 25
# feel free to use a closer mirror
$ wget
http://ftp.uni-kl.de/pub/linux/ubuntu.iso/20.04.1/ubuntu-20.04.1-desktop-amd64.iso
$ mv ubuntu-20.04.1-desktop-amd64.iso
/v
OK, sort of figured it out :-). Seems I need to also modify
/etc/apparmor.d/usr.sbin.libvirtd. Let me dig into that one separately
... LOL.
On the USB front, thinking a basic configuration file should be
sufficient for debugging - no drives needed, etc. Do you happen to have
one (or a partial) tha
OK, tried other USB controllers (piix4, vt82c686b), same issue - this is
really odd!
Thought I'd update to the latest / official v5.2.0 qemu, but now I get this
when trying to run it. Huh?!?!
error: internal error: Failed to start QEMU binary
/usr/local/bin/qemu-system-x86_64 for probing: libvir
OK, I got to thinking about this other bug I had seen a while back. Initially
thought it was not related, but maybe it is after all?
https://bugs.launchpad.net/qemu/+bug/1694808
Perhaps we are using different USB controllers, and that's why we see different
results? I have the following ... matc
> If you tell me how to initialize a mouse there I can try :-)
Sorry, bad wording on my part. The USB device I am connecting is a
Logitech Nano Receiver ... keyboard and mouse both connected to it. So
at the UEFI / Grub stage - only the keyboard, as you correctly point out
:-).
> It only matters
On Thu, Dec 10, 2020 at 1:41 PM Russell Morris
<1906...@bugs.launchpad.net> wrote:
>
> Thanks for the details! I thought we may be on to something, but not quite. I
> saw a couple deltas in your config (vs. mine),
> 1) No OVMF_VARS - tried removing this, no difference.
If not specified an empty t
Thanks for the details! I thought we may be on to something, but not quite. I
saw a couple deltas in your config (vs. mine),
1) No OVMF_VARS - tried removing this, no difference.
2) You are checking the mouse in the OS - checked that as well (not just UEFI /
Ubuntu Grub menu), nope, it's still no
> > I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/
>
> So you don't see this issue, or haven't had a chance to check it? No
> biggie either way, just trying to understand your comment :-).
Sorry to be unclear:
- I was not having the issues doing the same in the past.
- Nor di
> I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/
So you don't see this issue, or haven't had a chance to check it? No
biggie either way, just trying to understand your comment :-).
> Would you mind outlining your case on the upstream mailing list?
Yes, no issue at all - but
> I also here have to do a reset (of the guest), to get the USB to show
> up. So it really does seem to be an issue between QEMU and UEFI, agreed?
As it seems right now - yes
I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/
I can ping here once I have qemu 5.2 (just released)
Yep, makes sense ... but I have to admit, I screwed up. Sorry! Complete
bonehead on my part.
When I tested Ubuntu (guest), I was connected over VNC, so I didn't
correctly / properly test the USB interface. So, I re-checked, making
sure to use QEMU + UEFI (Tianocore, stock VARS), and check USB. It
>
> I get to the UEFI menu, but it won't seem to boot to my drive. Thoughts
> / suggestions?
I guess for that to work you'd have had to install it with UEFI
already present to prep the boot entries accordingly.
I'm not asking you to modify (and break) your existing guest.
Recommendation: just inst
Hmmm ... not getting Windows 10 to boot now. Trying to follow
https://k3a.me/boot-windows-partition-virtually-kvm-uefi/, set up os in my
config (xml),
hvm
/var/lib/libvirt/qemu/nvram/OVMF_CODE.fd
/var/lib/libvirt/qemu/nvram/win8.1_VARS.fd
I get to the UEFI menu, but i
> This particular rule is (re)loaded on guest start, so stop+start a
> guest and it is updated.
So no need to restart apparmor? And both entries are required (in the
libvirt-qemu file)?
> Yeah - kind of, and now the request it to test Ubuntu and Windows
> guest with the same OVMF based UEFI.
Fun
On Mon, Dec 7, 2020 at 4:05 PM Russell Morris
<1906...@bugs.launchpad.net> wrote:
>
> > Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is
> > better to now get conflicts on upgrades.
>
> Makes sense, thanks! Will move the items there. Both entries are needed?
> Seems like I can j
> Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is
> better to now get conflicts on upgrades.
Makes sense, thanks! Will move the items there. Both entries are needed?
Seems like I can just restart apparmor after (or at least that's working
for me).
> if the windows guest didn'
> On the apparmor issue, is this the "right" fix? I modified
> /etc/apparmor.d/abstractions/libvirt-qemu, adding,
> /usr/local/bin/qemu-system-x86_64 rmix,
> /usr/local/share/qemu/** r,
>
> Or is there a "better" (correct) way?
Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is
No worries, and thanks for all the help so far - it really is
appreciated!
On the apparmor issue, is this the "right" fix? I modified
/etc/apparmor.d/abstractions/libvirt-qemu, adding,
/usr/local/bin/qemu-system-x86_64 rmix,
/usr/local/share/qemu/** r,
Or is there a "better" (correct) way?
As f
Thanks for your feedback Russell.
You resolved the apparmor issue faster than I could reply :-)
About the actual issue, it indeed seems like an issue between UEFI and QEMU
here.
But I'm still wondering why it then would be any different with Windows and/or
Linux guests.
Is the UEFI in those Wind
FYI, was able to get the following version of QEMU running (using the info at
https://stackoverflow.com/questions/10817813/apparmor-causes-issues-on-libvirt-with-custom-qemu),
QEMU emulator version 5.1.93 (v5.2.0-rc3)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
No delt
OK, some interesting findings :-). And back to thinking it may be QEMU related?
Let me explain, by all means disagree!
1) I found that using OpenCore with macOS, I no longer need a custom UEFI. So,
I tried the UEFI that comes with Ubuntu (apt install ovmf, copied the files
over). No change. So t
I think we can agree that it is "guest dependent"
Either Windows has a way to fix up the issue or it doesn't even have it to
begin with (compare to MacOS).
Chances are that your (virtual) bootloader/UEFI are what breaks it to
begin with (and not the MacOS later). Do you think you could play aroun
> The one obvious next test would be to shut down the macOS guest and
try an ubuntu guest with the same forwards. That will allow us to see if
it is "virtualization-components" or actually "guest OS" that we need to
think about.
Good idea. OK, so I shut down all VM's, added this same USB device to
Hmm,
I was guessing the paths from your former log output.
Thanks for fixing it up as needed on your system.
So we know that just resetting it from the Host POV won't change anything.
And thanks for the info on "auto-recovering" on guest reboot.
The one obvious next test would be to shut down the
No issue with reboot, worry about that after we debug this :-). I tried the
noted command, but I get,
bash: echo: write error: No such device
bash: echo: write error: No such device
FYI,
$ ls -alF /sys/bus/pci/drivers/xhci_hcd/
total 0
drwxr-xr-x 2 root root0 Dec 2 17:51 ./
drwxr-xr-x 35 ro
The logs make total sense, thank you!
OK on lsusb:
We see the HID devices flip from "usbhid" driver to "usbfs" with the initial
start.
They no more change on the reset.
On the journal entries we see on the initial guest start that gnome has to
yield the devices (OK).
USB isn't mentioned at al
OK, let me try to explain what I did here - and yell if this is not
clear!
Step #1, check lsusb -t before any qemu start,
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub,
Sure, will add - NP! One comment on (2) ... I can't say if this happens
with other guests or not, as I only bind this USB device to this
particular (guest) OS.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/
(1) yeah makes sense now, thanks
(2) So we can't get good-vs-bad data, but is the behavior any different
at least with non MacOS guests then?
(3) no please no filtering - add all of it to see everything from
kernel-apparmor denials to anything odd with udev rules.
--
You received this bug notif
(2)+(3) bonus, since the device will need to be detached on the host to
be passed through and IIRC that depends a bit on USB topology. Can you
provide pre/booted/after-reset output of "lsusb -t" of the host as well
pelase?
--
You received this bug notification because you are a member of Ubuntu
B
Sure, NP at all! Let me try to answer, and yell if you need more details - I
will get them for you.
1) Reset ... meaning if I start the domain with 'virsh start macOS' => no USB
passthrough (Logitech nano receiver in this case). So then, I 'virsh reset
macOS' ... USB passthrough works fine! But
Hi Russel,
I haven't seen such issues recently, but let us try to sort it out.
For that I beg your pardon but I need to start asking for a few details:
1. what exactly (commands) does "reset of the VM" mean for you?
2. in the guest does the output of lspci -v (or whatever the macos counterpart
is
** Project changed: qemu => qemu (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906155
Title:
USB Passthrough Fails on Start, Needs domain Reset
To manage notifications about this bug go t
43 matches
Mail list logo
