null pointer reference in kernel-latest in QubesOS 4.0

[Peter Funk]

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

[Jin-oh Kang]

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)

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20211117225732.GA27178%40artcom0-ac50365.artcom-gmbh.de.

[Peter Funk]

Hi,

Thanks for taking the time to have a look at my problem.

On Thu, Nov 18, 2021 at 07:00:58PM +0900, Jin-oh Kang wrote:
> 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

[Peter Funk]

Hi,

On Thu, Nov 18, 2021 at 01:21:23PM +0100, I wrote:
...

> On Thu, Nov 18, 2021 at 07:00:58PM +0900, Jin-oh Kang wrote:
> > 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
--

Peter Funk; Oldenburger Str.86, 27777 Ganderkesee, Germany
homeoffice phone: +49-4222-950270