In a QubesOS 4.0 dom0 terminal I've tried the command::
sudo qubes-dom0-update kernel-latest
and discovered afterwards my Laptop reboots due to a kernel null
pointer reference during boot when I try this kernel.
The stable kernel works fine though.
I've tried to make a photo of the error message (see attached
.jpg file). Has anyone tried to boot the kernel from package kernel-latest?
Best regards, Peter Funk
libvirtd tried to assign the USB controller to a VM, and the USB controller was already attached to the driver (xhci-pci) in dom0. The bug was triggered while the driver was detaching itself.
Try one of the following:
Hi,
Thanks for taking the time to have a look at my problem.
libvirtd tried to assign the USB controller to a VM, and the USB controller
was already attached to the driver (xhci-pci) in dom0. The bug was
triggered while the driver was detaching itself.
Interesting. I've not changed my setup and I'm currently writing this
while running the same configuration with dom0 5.4.143-1.fc25.qubes.x86_64
So I think this bug is new. It was reproducable though. I've tried booting
the 5.13.6-1.fc25.qubes.x86_64 from kernel-latest at least five times in a row
to make sure it is no race condition.
Try one of the following:
- Temporarily detach the USB controller from the VM.
- Blacklist the xhci-pci driver in dom0. (create a .conf file with line
"blacklist xhci-pci" in /etc/modprobe.d)
I'm using an external keyboard, which is attached to my laptop through
one of it's USB controllers. Because I've usually mounted the laptop on
a stand, I don't want to be forced to use the internal keyboard to enter
the LUKS passphrase.
I will try blacklisting the xhci-pci as you suggested above and report
later, whether this made a difference.
Best regards, Peter Funk
Hi,
...
> libvirtd tried to assign the USB controller to a VM, and the USB controller
> was already attached to the driver (xhci-pci) in dom0. The bug was
> triggered while the driver was detaching itself.
...
> Try one of the following:
>
> - Temporarily detach the USB controller from the VM.
> - Blacklist the xhci-pci driver in dom0. (create a .conf file with line
> "blacklist xhci-pci" in /etc/modprobe.d)
...
I will try blacklisting the xhci-pci as you suggested above and report
later, whether this made a difference.
I have tried the second suggestion: At first this made no difference.
The kernel-latest (5.13) was still rebooting itself.
I took me a while to figure out that additionally I had to recreate
the initramfs belonging to this kernel using the following commands::
sudo mkinitrd new_initramfs-5.13.6-1.fc25.qubes.x86_64.img \
5.13.6-1.fc25.qubes.x86_64
sudo mv initramfs-5.13.6-1.fc25.qubes.x86_64.img \
initramfs-5.13.6-1.fc25.qubes.x86_64.img.orig
sudo mv new_initramfs-5.13.6-1.fc25.qubes.x86_64.img \
initramfs-5.13.6-1.fc25.qubes.x86_64.img
Afterwards I was able to boot into the new kernel. However now I had
to use the builtin keyboard of my laptop to enter the LUKS-Passphrase.
After startup of the sys-usb qube the external keyboard becomes usable
again.
Furthermore me and also some others in our german language Qubes-OS
user group noticed a new effect: After typing Enter in the LUKS passphrase
input field for some fractions of a second some blinking pixel gibberish
appears above the passphrase input field just before the screen
is cleared.
Neither of these problems were/are present in the stable kernel
vmlinuz-5.4.143-1.fc25.qubes.x86_64 I installed August 27th this year.
So I think those effects could be considered as regressions.
Best regards, Peter Funk
