Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/21/2024

Domain Index Total: 195

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 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 /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/crypttab on the root parition ( sda3_crypt in this example). All of these partitions must be present ( including /proc and /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 RSS Atom 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 lvm2 is 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/crypttab to ensure the update-initramfs command 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 apt install btrfs-progs 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-initramfs lead 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/fstab and /etc/crypttab from 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 -ay out. 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! Very helpful, thanks a lot for that post! As a quick note, this also works for the Virtualbox related installation. Ony difference would be to mount the LiveCD in the Settings > Storage > Controller: IDE and start the VM. The other steps work as a charm! As William (William - 13:54, 06 May 2018) did, I booted to the preceding kernel version, and as I logged in, I saw LivePatch flash by saying it had just updated something. I used apt to 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. reboot and go to BIOS using "fn and F2" BIOS > System Configuration > Sata Operation > switch to "AHCI" from "RAID On" 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: mount --rbind /sys /mnt/sys/ I didn't try the mount -o bind method with sys. My case was similar, but I had an additional issue. On my Ubuntu machine /usr/share/initramfs-tools/hooks/lvm2 was not set as executable. This caused it to be skipped when initramfs was built, leaving me with an initramfs without LVM. After making the file executable (chmod +x) and rebuilding initramfs, the system was bootable again. This is a superb guide, thanks! I had an additional problem and while running "update-initramfs -c -k all" I got the following error: cryptsetup: ERROR: Couldn't find sysfs directory for 253:2 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: mount -t sysfs /mnt/sys 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. # ramfs shell commands (initramfs) blkid #get the driver with LuKs crypt (initramfs) cryptsetup luksOpen /dev/luksdrive sameluksdrivenamethenappend_crypt (initramfs) vgchange -ay (initramfs) exit # 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. 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? I tried these method but not able recover from intrimfs terminal after implementing LVM encryption during installing then i decided to make a boot key to recover from boot with out asking any encrytion key Add a comment