Latest Kernel from current-testing causing boot loop

[Simon-Davies]

Qubes OS version
The version of Qubes OS you're using (e.g., R4.0), available via the command cat /etc/qubes-release in a dom0 terminal.

4.0.1

I just installed the latest Kernel from current-testing and selected it in Qubes Manager. After performing a reboot my system keeps rebooting after entering the LUKS password.

How do I select an older Kernel to get the system working again?

[marmarek]

Which kernel package? "kernel" (at 4.19.x), or "kernel-latest" (at 5.0.x)?

As for switching to older kernel, in case of legacy BIOS boot, go to "advanced" submenu in boot loader. In case of UEFI, you need to boot some rescue system, mount EFI partition, edit EFI/qubes/xen.cfg file and change default option at the top.

[Simon-Davies]

I've changed it from 4.19.36-1 back to 4.19.34-1 and it's booting fine now.

Thanks for your help.

[marmarek]

There are separate kernel packages for dom0 (what you see in xen.cfg and /boot) and VM (what you see in qubes manager). The one with VM has -qubes-vm suffix (kernel-qubes-vm, kernel-latest-qubes-vm).

[Simon-Davies]

Kernel 5.0.7-1 doesn't even get to the LUKS decryption screen. It goes black.

I'm reverting back to 4.19.34-1 that works.

Thanks marmarek.

[euidzero]

Same issue on Lenovo X1 carbon 5th Gen I7-7500U with kernel 4.19.67 : after displaying the efi info (kernel an initramfs version):

• if CSM is disabled in bios the system just wait
• if CSM is enabled the system reboots.

[euidzero]

The latest functional kernel for me is 4.14.74-1.

[marmarek]

@euidzero I have very similar hardware and don't see this problem. Right now I use 5.2.7 kernel, but 4.19.x also worked for me. Maybe you've run out of disk space in /boot/efi and initramfs generation failed? Check how much space you have and and regenerate initramfs with sudo dracut -f /boot/efi/EFI/qubes/initramfs-4.19.67-1.pvops.qubes.x86_64.img 4.19.67-1.pvops.qubes.x86_64

[euidzero]

Will try and report. In the meantime: is there any low risk way to raise the size of /boot (with is 200mb there) ? Thx Le dim. 1 sept. 2019 à 18:37, Marek Marczykowski-Górecki < notifications@github.com> a écrit :

…

@euidzero <https://github.com/euidzero> I have very similar hardware and don't see this problem. Right now I use 5.2.7 kernel, but 4.19.x also worked for me. Maybe you've run out of disk space in /boot/efi and initramfs generation failed? Check how much space you have and and regenerate initramfs with sudo dracut -f /boot/efi/EFI/qubes/initramfs-4.19.67-1.pvops.qubes.x86_64.img 4.19.67-1.pvops.qubes.x86_64 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4997?email_source=notifications&email_token=AADLUHDALAYGMGMS3H53JULQHPVTBA5CNFSM4HIHRCG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UGEGI#issuecomment-526934553>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADLUHHY6YU7NZSPJAVGDN3QHPVTBANCNFSM4HIHRCGQ> .

[marmarek]

Depending on partition layout, but in most cases no.
Related: #3224

[euidzero]

First initramfs was not correctly generated but this occured completely silently. Not first time I see this on dom0 when out of space on /boot. So maybe a dracut bug ?
Second : even with initramfs looking good (size seems correct compared with previous version) same problem :

• UEFI + CSM on : lock up right after displaying xen EFI configuration.
• UEFI +CSM off : boot loop

My BOOTX64.cfg (working, substitute kenrel version for non working config) :

[global]
default=4.14.74-1.pvops.qubes.x86_64

[4.14.74-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-4.14.74-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-0a8078af-a2b8-436c-9c80-28178d733bec rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.preliminary_hw_support=1 rhgb quiet psmouse.synaptics_intertouch=0 plymouth.ignore-serial-consoles
ramdisk=initramfs-4.14.74-1.pvops.qubes.x86_64.img

[euidzero]

kernel-latest (5.2.9-1) is booting correctly.

[marmarek]

I assume it was out of disk space issue, more details in #5038)