[qubes-users] null pointer reference in kernel-latest in QubesOS 4.0

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:

  • 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)

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