8

I've reproduced this twice from a fresh install - the setup initially works fine, but when a kernel update is applied, the system hangs on reboot. Selecting the older kernel I have available from GRUB works fine.

System details:

  • XPS 13 9380
  • i5-8265U
  • BIOS version 1.15.0
  • Microcode version reported as "0xea". Output of apt list --installed | grep microcode: intel-microcode/hirsute-updates,hirsute-security,now 3.20210608.0ubuntu0.21.04.1 amd64 [installed,automatic]
  • Secure Boot is, I believe, set to audit mode.
  • Ubuntu hirsute (as mentioned)
  • Installed on a LUKS partition from LiveUSB
  • Currently on 5.11.0-37-generic but I've reproduced with older 5.11 kernels as well. Definitely seems to be the change in kernel version rather than the version itself. 5.11.0-36-generic boots with no unusual GRUB options required.

GRUB settings I've tried that definitely do not work:

  • dis_ucode_ldr and mitigations=off (together or separately);
  • nomodeset
  • removing quiet splash
  • recovery
  • debug (no change in output)
  • any form of echo after the line "initrd /initrd.img-5.11.0-37-generic"

And all permutations thereof.

lsinitramfs of both initrd.img and initrd.img.old (that I can boot off of) files doesn't pop up any obvious candidates.

It seems to likely be either microcode or cryptsetup-related, but since debug gives nothing, and dmesg presumably reports a normal boot once I boot with 36, I'm slightly at a loss.

Any thoughts? There seem to be related bugs but nothing that exactly reproduces.

Bereded
  • 81
  • 1
  • 2

3 Answers3

6

Solution: use

MODULES=dep

in the /etc/initramfs-tools/initramfs.conf.

And regenerate with (replace 5.11.0-37-generic with the kernel version you are using):

update-initramfs -c -k  5.11.0-37-generic

I've hit the same issue as the OP. After an update and a reboot a few days ago, the system hangs on "Loading initial ramdisk..." and no other output.

My hardware is almost identical but for the CPU: i7-8565U. Same software configuration as listed in the OP.

Another post suggests the following:

The problem originates from large initrd.img files (~100MB) generated with MODULES=most that can't be loaded due to size limitations. This can be solved by switching to MODULES=dep which generates initrd.img files of approximately 55MB.

terdon
  • 234,489
  • 66
  • 447
  • 667
Sorin Jianu
  • 61
  • 2
3

I believe I hit this issue today as well and it took me a good few hours to resolve. The resolution was to rebuild the boot image, which was ~160MB and likely too large (as described by Sorin). However the process to do so took a bit of figuring out.

Machine

  • Dell XPS 9550
  • Ubuntu 20.04
  • UEFI Boot partition: nvme0n1p2
  • LUKS encrypted primary partition: nvme0n1p3

Symptoms

On boot, instead of the LUKS password prompt I was greeted with the grub menu. Choosing Ubuntu lead to a blank screen. Attempting to boot in recovery mode would get as far as "loading initial ramdisk" before freezing. As with Bereded (OP), I tried a whole range of GRUB config flags and BIOS settings to no avail.

Solution

We need to boot from USB, change the initramfs-tools config, then rebuild the initrd.img.

  1. Boot from a live USB
  2. Decrypt/unlock the primary partition (replace nvme0n1p3 with your encrypted partition name) 
    sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt
  3. Mount the encrypted partition to /mnt, the boot partition to /mnt/boot, then chroot /mnt 
    vgscan --mknodes
vgchange -ay
sudo mount /dev/mapper/vgubuntu-root /mnt # may be named ubuntu--vg-root depending on your system
sudo mount /dev/nvme0n1p2 /mnt/boot  # replace nvme0n1p2 with your boot partition
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
  4. From the chroot shell, open and edit /etc/initramfs-tools/initramfs.conf, set: 
    MODULES=dep
  5. Take a backup of your current/latest initrd.img. e.g 
    mv /boot/initrd.img-5.13.0-44-generic /boot/initrd.img-5.13.0-44-generic.bak
  6. Rebuild the image (replace with current kernel version) 
    update-initramfs -c -k 5.13.0-44-generic
  7. Update grub 
    update-grub
  8. Exit and reboot, you should now be able to boot from the rebuilt image

Troubleshooting

The name you give the mapped device when calling cryptsetup luksOpen is important - it should match the volume name configured in your crypttab (which you can't see yet because you haven't unlocked/mounted the partition). By convention, it should be <device_name>_crypt. If this is incorrect, you'll get the following warning when running update-initramfs.

cryptsetup: WARNING: target '<Device UUID>' not found in /etc/crypttab

Resources

DBrowne
  • 131
  • 2
  • Your answer, in combination with Sorin, helped me fix the issue. I could boot into recovery mode, so I didn't have to use a live USB. For anyone else with this problem, make sure you run **BOTH** ```sudo update-initramfs -c -k ``` and ```sudo update-grub``` – snowskeleton Jun 08 '22 at 21:09
0

Typing the (correct) LUKS password and confirming with enter - as if the dm-crypt promt were there - resulted in a regular boot, for me.

(have experienced this on a current Debian (netinstall) as well as on Alpine Linux)

Martin
  • 183
  • 1
  • 8