1

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.

2

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!

| improve this answer | |
0

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.

| improve this answer | |
New contributor
KoenBal is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 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 18 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.