Hi,
The same issue here - it wants to force me back to nvidia-driver-470. Is
there a way around this?
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1963976
Title:
Installing
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,
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
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
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
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 -
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
|__
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)
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:
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 ...
> 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
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
> 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 -
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
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
> 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.
> 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
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
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
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
> 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
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
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,
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.
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,
Seeing this same thing! And I'm on Ubuntu 20.10, so pretty current :-).
vt82c686b-usb-uhci doesn't seem to be accessible any more, but trying
qemu-xhci => no joy, still have to reset the VM after each startup, to
get the keyboard and mouse working.
Is this expected?
Thanks!
--
You
Sorry, not understanding your "fix" here. I tried the change you note,
and restarted x11vnc (server) ... it's still not listening on the
defined ports.
Or is this not to fix x11vnc?
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hmmm ... you mean you logged in with that Window Manager? I can't even
connect to the machine any more - and checking it locally, the same
issue here ... it's not even listening on the port any more.
Thanks though!
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Arrgh ... OK, was having issues getting the new desktop working.
Uninstalled / reinstalled the display manager, moving it from lightdm to
gdm3 (the default, right?) => now VNC is broken on the second machine as
well ... :-(.
--
You received this bug notification because you are a member of
Hi,
Interestingly enough, I just upgraded a machine from 17.04 to 17.10 ->
VNC works fine. But the machine that was on the alpha / beta builds
still isn't working.
Hmmm ... is there a way to "clean reset" x11vnc on the machine that was
running older builds? Seems this should be able to work.
Public bug reported:
Hi,
x11vnc is running fine on my other machines (running earlier versions of
Ubuntu). But in Artful Aardvark (17.10), I have checked the service ... it's
active (running), and shows this pid/ command line,
1816 /usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat
Hi,
Just recently upgraded (16.04 LTS => 17.04), and I can confirm this bug
and workaround / fix as well. It definitely exists in 17.04.
Is the fix "OK"? Meaning what does it potentially break?
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Interesting - as I'm having to go back to 4.4.0-89 to get my machine to
boot ... kernel panic and hang on 4.4.0-91. I'm happy to take logs, just
not sure how to ... :-(
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
33 matches
Mail list logo
