5

Ubuntu is not booting but printing weird things, either

  • /run/lvm/lvmetad.socket: connect failed: No such file or directory
  • or /sbin/cryptsetup not found

then falls back to busybox after a few minutes (sometimes..).

The error appeared after moving onto a new hard disk where I had to delete an encrypted partition. After chrooting into the root partition and running udpate-initramfs -u the error mentioned in this Ask Ubuntu question popped up:

cryptsetup: WARNING: could not determine root device from /etc/fstab

I followed the setup proposed in this article: Full disk encryption with Ubuntu. Now I have a / btrfs volume inside LUKS with an unencrypted /boot partition. All this running on EFI with secure boot disabled.

Zanna
  • 70,465
matt3o
  • 941

2 Answers2

9

Had a very similar issue after an update of Ubuntu 20.04 on a Dell XPS13 (2020). Searched for hours, the solution was actually 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.

KoenBal
  • 169
  • 1
  • 2
  • 1
    You have posted this answer to several different questions saying you "had a very similar issue". I appreciate that you want to help, but I feel it would be easier for readers to judge whether to try your solution if you specified exactly what problem you had. IIRC, switching SATA mode could make some installed systems unbootable (one may have to reinstall after doing it). It is rare that an identical answer is applicable to many different questions. Please do check the details of the question carefully when answering (basic example - keys to access BIOS are hardware dependent). – Zanna Jul 15 '20 at 08:18
  • 6
    I had the same issue with Dell XPS 15. The booting usually failed on trying to initialise the luks partition (“timed out waiting for device dev-disk-by/...”).

    I agree that it is a bit unintuitive advice, but it helped me a lot. At least this answer seems to have been the easiest to find with google.

     – Karel Lenc Aug 28 '20 at 19:14
  • This resolved my issue after my battery died on a Dell XPS 15 7590. Changing the setting back in BIOS allowed for boot to properly access and decrypt. You will get a warning that the system may become unbootable if not meant to be using AHCI, and that you may have to reinstall. So, for those giving this a shot, would be good to keep in mind in case this may not be your issue or the proper solution depending on the root cause. Everything I have is properly backed up and I configure my OS with Salt, so the risk was low in the event that I'd have to wipe. I couldn't access anyway. – ScriptAutomate Feb 06 '23 at 01:15
  • For me, installing a slightly older kernel and updating grub to boot to it caused this. Thank you so much! – lane Dec 18 '23 at 17:34
5

All the default hacks and fixes are putting you on a good track, however none of them was complete. This was the solution in my case:

  1. Make sure the /etc/crypttab file is set up correctly. All entries have to refer to existing partitions. There should be at least one entry named "root", this is the root / entry. This was crucial for me - and nobody mentioned it so far!
  2. This entry should be referred to in the /etc/fstab with /dev/mapper/root. Check that the UUIDs are correctly set up
  3. Now run update-initramfs -u which udpates only your most recent kernel. If a cryptsetup warning pops up, you failed on the previous steps. Review all files and try figure out the problem
  4. Run update-grub to fix any remaining grub issues
  5. Now check the /boot/grub/grub.cfg. Go search for the first menuentry which is the one that will be booted. The search part should contain the UUID of the boot partition (unencrypted!). The linux part should have something saying that root=/dev/mapper/root or pointing to the UUID of the unencrypted volume (in my setup the btrfs volume)
  6. Try to boot. If the lvm errors still pop up, silence them as mentioned in this answer

One last advice: Care for any little warning popping up. Usually they are meaningless, in this case they are very important.

Good luck!

matt3o
  • 941
  • I don't suppose you could add your chroot steps? This is not working for me. – Chaim Eliyah May 06 '21 at 01:40
  • 1
    Sure. Just replace $mount_path with the actual device you need to mount.

    sudo mount $mount_path /mnt sudo mount -o bind /dev /mnt/dev sudo mount -o bind /sys /mnt/sys sudo mount -t proc /proc /mnt/proc sudo cp /proc/mounts /mnt/etc/mtab sudo cp /etc/resolv.conf /mnt/etc/resolv.conf sudo chroot /mnt

     – matt3o May 10 '21 at 06:28
  • Thanks, I eventually figured it out but hopefully this will help someone else. :) – Chaim Eliyah May 11 '21 at 18:41
  • I recently had to fix my Ubuntu 23.04 boot setup and this gist describes the steps in detail that worked for me. https://gist.github.com/bmiller59/2297db9d8df4a2fb39daceb82fe578e2 – bmiller59 Aug 08 '23 at 23:02