For many years now I've been an avid windows & mac user. Most recently, the growing love-affair between tech corporatists and government bureaucrats has convinced me to take the plunge into the world of open-source. My transition was going smoothly up until I F'd the boot process. For days now I've been trying to resolve this problem. I figure--before I completely start cry running back into Tim Cook's arms--I should ask the smart folks on here for help.


My linux distro is setup on a single partition with encrypted LVM (sda5_crypt). There are two kernel images (4.19 & 5.9) available on the boot partition. I may have messed up my initrd image while doing a sudo apt-get purge --auto-remove lvm2 or possibly while monkeying around with the crypttab and/or fstab files followed by a sudo update-initramfs -u.

The Big Problem

Now after GRUB loads kernel 5.9 into memory, I am dropped into the initramfs shell, the kernel is searching in /dev/sdd and so forth. Also, the vgscan and pvscan show "no medium found" on /dev/sdd and so forth. Of course! This is strange since the distro is setup on sda5. I'm also unable to exit out of the shell.

Attempted Solutions

I've tried--without real success--temporarily changing the root= parameter in the GRUB Bootloader, duplicating initrd image (4.19) for initrd image (5.9), etc. Perhaps one silver lining here is that, when selecting kernel 4.19 image from the GRUB boot menu, I am able to successfully decrypt the disk and boot into the distro's shell. But how the heck then am I supposed to update-initramfs for kernel 5.9 when I have kernel 4.19 loaded!?! It feels like the twilight zone.

Any suggestions from you linux veterans is very much appreciated!

  • I'm going to be blunt; at this point, and at your current professed skill level, it's probably a better bet to reinstall from scratch. If you still have the key/passphrase to your encrypted storage you should be able to recover your personal files using a live image. Jan 29, 2021 at 14:58
  • I've got 25+ years of experience with linux myself and maybe if I had been the one who installed it and if I remembered exactly what I did just before it went tits-up and if I had full access to the system I might be able to coax it back to life, but it'd take days of frustrating effort. Jan 29, 2021 at 15:00

1 Answer 1


I got it working! Here are the steps that got the problem resolved. Hopefully this will help a future someone that's in the same pickle:

  • If you have some other way to access your system--such as another kernel installed (as was my case)--then you do not need to chroot. Just select that kernel from the GRUB menu and log-in to your system. I was able to get into the terminal shell.

  • Get the UUID of all your block devices using sudo blkid. Open-up your /etc/fstab file and replace the kernel name descriptors (i.e. /dev/sda1) with UUID. This is important because kernel name descriptors are not persistent. Take note also that there's an issue with MBR/GPT partition types (reference). After all is said and done, you should have something like this:

UUID=XXXXXX-XXXXXX-XXXXX-XXXX-XXXXXX /      ext4    errors=remount-ro 0    $

UUID=XXXXXX-XXXXXX-XXXXX-XXXX-XXXXXX /boot  ext2    defaults          0    $

UUID=XXXXXX-XXXXXX-XXXXX-XXXX-XXXXXX none   swap    sw                0    $
  • Now open-up your /etc/crypttab file. There should only be one entry here per encrypted device. The first column is the device mapper's name (reference) and should not be the UUID (as was in the fstab file). You can find the device mapper's name in the blkid print-out. It usually is listed as /dev/mapper/sda5_crypt. Note, however, that the UUID in the crypttab file is NOT THE SAME as the one found on the blkid line for dev/mapper/sda5_crypt. Instead the correct UUID that must be used in the crypttab file can be found on the blkid line for /dev/sda5. In the end you will have something like this:

sda5_crypt UUID=XXXXXX-XXXXXX-XXXXX-XXXX-XXXXXX none luks,discard
  • Then go to your boot directory (i.e. /boot). Make a backup of your vmlinuz file (i.e.vmlinuz-5.9.0-0.bpo.5-amd64).

  • Now you need to run the command to update your vmlinuz file for the specific kernel (reference). The u is for "update." The v is for "verbose" (live print-out of everything). The k is for the specific "kernel" version that you will be generating the initramfs image. The command:

sudo update-initramfs -uvk 5.9.0-0.bpo.5-amd64
  • Now search through the verbose noise. Make sure there are no errors when generating the image. If none, reboot your system and voila!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .