A laptop that was installed using the default Ubuntu 16.10 (xenial) full-disk encryption option stopped booting after receiving a kernel update somewhere on the way to Ubuntu 17.04 (zesty).
After showing the boot screen for about 30 seconds, a busybox shell pops up:
BusyBox v.1.21.1 (Ubuntu 1:1.21.1-1ubuntu1) built-in shell (ash)
Enter 'help' for list of built-in commands.
(initramfs)
Typing exit will display more information about the failure before
bringing us back to the same busybox shell:
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/ubuntu--vg-root does not exist. Dropping to a shell!
BusyBox v.1.21.1 (Ubuntu 1:1.21.1-1ubuntu1) built-in shell (ash)
Enter 'help' for list of built-in commands.
(initramfs)
which now complains that the /dev/mapper/ubuntu--vg-root root partition
(which uses
LUKS and
LVM) cannot be found.
There is some comprehensive advice out there but it didn't quite work for me. This is how I ended up resolving the problem.
Boot using a USB installation disk
First, create bootable USB disk using the latest Ubuntu installer:
- Download an desktop image.
Copy the ISO directly on the USB stick (overwriting it in the process):
dd if=ubuntu.iso of=/dev/sdc1
and boot the system using that USB stick (hold the option key during boot on Apple hardware).
Mount the encrypted partition
Assuming a drive which is partitioned this way:
/dev/sda1: EFI partition/dev/sda2: unencrypted boot partition/dev/sda3: encrypted LVM partition
Open a terminal and mount the required partitions:
cryptsetup luksOpen /dev/sda3 sda3_crypt
vgchange -ay
mount /dev/mapper/ubuntu--vg-root /mnt
mount /dev/sda2 /mnt/boot
mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev
Note:
When running
cryptsetup luksOpen, you must use the same name as the one that is in/etc/crypttabon the root parition (sda3_cryptin this example).All of these partitions must be present (including
/procand/dev) for the initramfs scripts to do all of their work. If you see errors or warnings, you must resolve them.
Regenerate the initramfs on the boot partition
Then "enter" the root partition using:
chroot /mnt
and make sure that you have the necessary packages installed:
apt install lvm2 cryptsetup-initramfs
before regenerating the initramfs for all of the installed kernels:
update-initramfs -c -k all
I successfully used your recommended approach without booting via USB. This can be accomplished by selecting to boot into a previous kernel via the Grub boot menu during startup, and then (without the need to mount local partitions) simply ensure the latest version of
lvm2is installed and regenerating the initramfs for all of the installed kernels (as recommended). I also have a fully encrypted drive configuration and found no issues when performing these steps.Thank you for putting this article together. While I normally find the forums to be of great assistance, this issue was not one that is easy to find real working solutions for. Keep up the great work.
I wanted to make sure the next time it happens I could recover quickly with just the LiveCD available.
I wrote it to detect the correct name from the
/mnt/etc/crypttabto ensure theupdate-initramfscommand can properly update.https://gist.github.com/dragon788/e777ba64d373210e4f6306ad40ee0e80
I got the same problem after upgrading to 18.04, I don't use LVM but Btrfs, all I had to change was
Everything else was exactly the same.
Thank you.
I didn't need to install
lvm2, as it was on my unbootable system. I also had some minor partition/volume differences.My issue is documented at the Ubuntu forums
That all said, I did have a major issue with DNS resolution not functioning after this was done. I'm wondering if
update-initramfslead to this issue specifically (I made other changes I can't recall clearly).If other experience loss of DNS via systemd.resolved failure, please note it here and on my post in the Ubuntu Forums. My fix is listed there, although I'm effectively disabling systemd.resolved.
First I recovered the
/etc/fstaband/etc/crypttabfrom the backup with backup-tool because I had tried something and messed up these files.Then I followed these instructions but I left the command
vgchange -ayout. Reason for that was because after that I couldn't mount my partitions to anything. Without it mounting was done nicely and the rest of the steps could be done.It had the consequence that in the end I couldn't unmount and close the partition but that wasn't in this instruction and so I paid no attention to that.
I encountered the problem when updating the initramfs (I was missing some firmware library and it gave some warnings). Solution to that was found here and the updating of initramfs were done without warnings.
In the end I prayed a little and rebooted and everything was fine after these changes and now I can log in to my ubuntu again.
Thanks for clear instructions!
aptto update everything and restarted, my machine is now running like a Swiss watch!Hello,
i have tried out your solution after failing about the one which did not help you also. But seems i am stuck in this update nightmare.
If you have any idea how to solve this i would be very greatful!
Had a very similar issue after an update of Ubuntu 20.04 on a Dell XPS13 (2020). Searched for hours, the solution was actually super easy.
For some reason, this BIOS setting was switched.
This helped a lot. Thanks! For a younger Ubuntu (20.04), I also had to mount /sys:
I didn't try the mount -o bind method with sys.
This is a superb guide, thanks!
I had an additional problem and while running "update-initramfs -c -k all" I got the following error:
Google couldn't answer anything about this error, but I finally figured it out - you just need to mount the sysfs (just like you mounted /proc and /dev). So just run this command:
Now when you run update-initramfs again the error should be gone and you can boot to your Linux again!
This suggested fix does not require a live OS.
Hello - thanks for this info I've had the exact same issue and am now able to boot. Just struggling with the 2nd part of the fix;
system boots normally
fixing issue
edit /etc/crypttab
rename the first space delimited
occurrence with sameluksdrivenamethenappend_crypt
quit n save
finally run
root@ubuntu# update-initramfs -u -v
finally reboot
fixed.
I can't seem to edit the crypttab file to start with, do you know which viewer i should be using? And then is it simply a case of adding the _crypt to the first space delimited occurence?