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.

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
0
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

Improve this answer
1
  • 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 <kernal version> and sudo update-grub Commented Jun 8, 2022 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)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.