Gave up waiting for root device, ubuntu--vg-root doesnt exist

Question

today I installed Ubuntu 64-bit on a netbook. When the netbook boots this, error report appeared. I think there is a problem with the partitions.

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)

Output of lsblk as requested:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 232.9G  0 disk 
├─sda1   8:1    0   231G  0 part 
├─sda2   8:2    0     1K  0 part 
└─sda5   8:5    0     2G  0 part [SWAP]
sr0     11:0    1   1.2G  0 rom  /cdrom
loop0    7:0    0   1.1G  1 loop /rofs

run lsblk and add the output to your question. – psusi Jan 01 '15 at 19:54 — psusi, Jan 01 '15 at 19:54
@psusi What if lsblk is not available? – sitilge Aug 15 '15 at 20:06 — sitilge, Aug 15 '15 at 20:06

lumbric · Answer 1 · 2021-02-01T18:07:40.620

38

In certain Ubuntu versions (e.g. Xubuntu 18.10) this issue might be caused by an apt autoremove. Due to this bug apt will suggest to remove

cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run dmeventd libdevmapper-event1.02.1 liblvm2app2.2 liblvm2cmd2.02 libreadline5 lvm2

which makes the system non-bootable (because the root partiation cannot be mounted and unencrypted using LVM).

If you are not using LVM and disk encryption this answer is probably not for you.

I was able to fix it by re-installing cryptsetup and lvm2 in a chroot environment: boot from a live USB stick, run commands below in a terminal, reboot.

# find root partition
sudo fdisk -l
unencrypt partition
Note: replace /dev/nvme0n1p3 with your disk
replace "nvme0n1p3_crypt" with the correct name
check by running this in chroot:
$ cat /etc/crypttab | cut -f1 -d " "
nvme0n1p3_crypt
sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt
mount root partition
sudo vgscan 
sudo vgchange -ay
sudo mount /dev/mapper/xubuntu--vg-root /mnt
prepare chroot environment
sudo mount /dev/nvme0n1p2 /mnt/boot/   # replace nvme0n1p2 with your boot partition!
sudo mount -o rbind /dev/ /mnt/dev/
sudo mount -t proc proc /mnt/proc/
sudo mount -t sysfs sys /mnt/sys/
make dns available in chroot
sudo cp /etc/resolv.conf  /mnt/etc/resolv.conf
enter chroot
sudo chroot /mnt /bin/bash
re-install missing packages
apt install cryptsetup lvm2
re-generate  (this might be done also by apt in the step before, I'm not sure)
update-initramfs -u -k all
Leave chroot environment - not sure if the following is really necessary...
exit
Write buffers to disk
sudo sync
Unmount file systems
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/boot

This Q&A helped me collecting the commands.

This Q&A is kind of related, but maybe not relevant for you anylonger if you are having this issue already.

edited Feb 01 '21 at 18:07

answered Feb 24 '19 at 20:48

lumbric

3,994

4

Ohh, you just saved me about three days of work I'd put into setting up a new device. Worked perfectly! Replaced nvme0n1p3 with sda5 and nvme0n1p2 with sda1 (linux partition inside the LVM and the small boot partition outside the LVM, respectively) – Oliver U Feb 26 '19 at 16:51
1

@OliverU great that it worked! Even if you can't make it boot anymore, you should be still able to copy your home directory and maybe parts of /etc or so to a fresh install. That should be probably less work than the inital setup. – lumbric Feb 27 '19 at 12:10
3

Worked perfectly for Ubuntu 18.10, where the problem happened to me after apt autoremove issue. Like Oliver above, I just had to replace the following in the instructions: nvme0n1p3 → sda5, nvme0n1p3 → sda5_crypt, nvme0n1p2 → sda1. Wit the right guess like that, no need to enter chroot twice as cat /etc/crypttab | cut -f1 -d " " inside chroot will just confirm you made the right guess. If you need to enter twice, do so after a reboot as closing and reopening the crytpsetup + LVM2 environment without rebooting seems … complex. – tanius Sep 29 '19 at 20:58
Also to note, these instructions worked great with the non-booting hard drive put into a drive enclosure and attached to another (properly working) Ubuntu computer via USB. No need for a live system then. – tanius Sep 29 '19 at 20:59
Thanks man, this helped after 4 hours of trying to fix this. Works even on Ubuntu 19.10 – WellBloud Oct 25 '19 at 10:40
This greatly helped me as well after I accidentally deleted some apparently important packages (even though cryptsetup and lvm2 were not directly removed). I accidentally did this: sudo apt remove busybox-static fakeroot git dmsetup kpartx netcat-openbsd nmap python-psycopg2 python3-psycopg2 snmp uml-utilities util-linux vlan. And then an apt autoremove which seems to have done the damage. – grssnbchr Nov 15 '20 at 21:00
I think I had the same problem some time ago, but in my case I was still able to boot with an older kernel and then reinstall the autoremoved packages directly. If that is an option it might be considerably easier than the above. – tobias_k Feb 01 '21 at 10:04
3

In my case, the missing bit was apt install cryptsetup-initramfs from chroot environment. – Adobe Jul 12 '21 at 10:55
1

In my case, nothing seemed to get installed when I ran apt inside the chroot shell. I think what did the trick was modifying /etc/crypttab (inside the chroot shell) to say nvme0n1p3_crypt UUID=[…] none luks,discard instead of crypt_dev_nvme0n1p3 UUID=[…] /etc/luks-keys/crypt_dev_nvme0n1p3 luks,discard. But I don't know for sure. – Simon Alling Jan 17 '22 at 17:48
1

This helped me a lot. Thanks! – Anar Amrastanov Jan 25 '22 at 23:34
1

Saved me from having to reinstall, thanks – P Varga Dec 21 '22 at 00:11
It was very helpful. At first, I thought my system was lost. Now it is repaired, worked for 20.04 version. Thank you! – Lysenko Andrii Feb 22 '23 at 17:27
Incredible answer. xubuntu--vg-root was ubuntu--vg-root for me. Also worth noting that cat /etc/crypttab | cut -f1 -d " " should be run from within chroot – forgetso Aug 02 '23 at 11:09
A few questions / comments for @lumbric if he is still updating this answer: – rik-shaw Dec 14 '23 at 19:46
I think you have to unencrypt to then read /etc/crypttab to find the correct volume name. If it needs changed, then have to either restart or close the volume, re-encrypt, and start again, unencrypting with correct volume name? Not sure if there is an easier way? Anyway, may need clarifying?

rik-shaw

Dec 14 '23 at 19:56

The syntax of the mount commands with -t were giving me some problems. Instead is it OK to adjust syntax to sudo mount --bind /proc /mnt/proc (and same for /sys)?

– rik-shaw Dec 14 '23 at 19:56

score 17 · Accepted Answer · edited Apr 13 '17 at 12:37

17

Please add the outputs of lsblk -fs, fdisk /dev/sda with p flag and the report of grub repair to the question as pastebin links.

Based on searching, there seems to be similar questions on Ask Ubuntu that has no answer up to date here and Here one answer is given which explains about raid and ubuntu.

There seems to be several suggestions, some of which seem to work for some people.

From the initframs prompt try typing ls /dev/mapper and see if your root volume is listed. If it is not listed, try waiting 10 seconds and run ls again.

If it is now listed, type exit and it should now find the root device and boot (taken from here
Edit the boot config by pressing e when grub alert to choose OS, and replace root=UUID-6500... by root=/dev/sdx where sdx is the boot partition. The problem here seems to be that the UUID is either wrong, or /dev/disk/by-UUID... does not exist(1)
Adding the parameter all_generic_ide to the end of the boot-line like kernel /boot/vmlinuz-2.6.27-7-generic root=UUID=43206294-74ef-434d-aca2-db74b4257590 ro quiet splash all_generic_ide seems to work for some people (2)
The Super User question here, seems to suggest the error is due to LVM. The solution is also given in the same which is to install lvm2.
The same Super User site also suggests booting using an older Kernel, if available. It seems to work for some people. Trying to boot using the Recovery option might work for some people
Post by nux_man777 here seems to suggest the error may be in the installation medium.
The error /dev/mapper/ubuntu-vg-root seems to be related to raid as described here.

"In the installer summary screen right before the copy process starts, click the Advanced button. Change the boot partition (this is the MSDOS-style "parent" partition not the Linux partitions) to /dev/mapper/pdc_feddabdf (or whatever dmraid lists as your fakeraid partition) Make sure the checkbox is clicked to boot from this disk. note that the installer will modify grub2 to point to the correct logical partition /dev/mapper/pdc_feddabdf1 or whatever / is on."

Detailed instructions regarding installation is given in the referred site. Please check there for more info on installation of grub.
Booting into a live installation media and updating ubuntu by changing root using chroot seems to work for some people (suggested by cpttripzz here). Instruction regarding chroot is here. You can also refer to this question at Unix & Linux. More details can be found at Arch Wiki and Gentoo Wiki.
Changing the SATA Controller to Native IDE from RAID and doing a fresh install seems to work for some people here and here
IDE cable or the hard disk may be bad (the same ubuntu forum as above page 40)

edited Apr 13 '17 at 12:37

Community

1

answered Jan 02 '15 at 04:51

One Face

321

The previous os was Win7 – Jonas Franz Jan 02 '15 at 12:30
fdisk http://hastebin.com/wayiqowine.rib – Jonas Franz Jan 02 '15 at 12:46
lsblk --fs http://hastebin.com/vadapinoro.hs – Jonas Franz Jan 02 '15 at 12:47
Boot Repair: http://paste.ubuntu.com/9660149/ – Jonas Franz Jan 02 '15 at 16:47
Error Message: http://postimg.org/image/tzuyske3d/ – Jonas Franz Jan 02 '15 at 16:52
@JonasFranz please post the output of ls. The command lsblk - fs shows no partition type. – One Face Jan 03 '15 at 00:10
The boot repair says installing grub for i386 machine. Which contradicts what you said about installing 64 bit os – One Face Jan 03 '15 at 00:44
Post the output of lsblk - f and mount commands too. To get more answers, post the output of both these commands in your question as html links – One Face Jan 03 '15 at 00:48
befor I installed 32bit I have installed 64bit. The same error. – Jonas Franz Jan 03 '15 at 08:30
mount – Jonas Franz Jan 03 '15 at 10:38
lsblk - fs @C-Rags – Jonas Franz Jan 03 '15 at 10:40
lsblk -l – Jonas Franz Jan 03 '15 at 10:42
I won't be free for 2 more hours. Call me again for chat in 2 hours – One Face Jan 03 '15 at 11:23
I call you at 8PM (Berlin timezone) – Jonas Franz Jan 03 '15 at 13:04
Please check the edited answer – One Face Jan 04 '15 at 15:04

score 9 · Answer 3 · edited Mar 23 '18 at 12:44

I had this problem and nothing on any posts here or elsewhere were able to help. Specifically in my case, I could see that /dev/mapper did not contain ubuntu--vg-root or anything else for that matter. This means that something either went wrong when LVM tried to mount/map the volumes OR something went wrong earlier in the boot process, and this error is just a catch-all symptom for any earlier problem.

The second of these was the case for me and only because of my reading about initramfs I was able to understand and diagnose the issue. This should be the first thing you do if you suspect something has gone wrong prior to LVM doing its thing.

In my case (which may not be the same as you but is worth documenting), I had full disk encryption (LUKS) enabled, and somehow the cryptsetup tools had been removed from initramfs, therefore I was not being prompted for the passphrase to unlock, and the drives were not accessible, which meant that /dev/sdaX could not be mounted, and therefore ubuntu--vg-root could not be mounted/mapped into /dev/mapper. If you try to run cryptsetup from the BusyBox prompt, youll know you have the same issue if thecryptsetup` cannot be found.

The solution was to boot from a LiveCD, unlock the drive manually with cryptsetup, chroot into the root filesystem, reinstall cryptsetup and call update-initramfs.

Welcome to Ask Ubuntu! :-) Can you expand the last line into actual commands? — Fabby, Mar 23 '18 at 12:24
I wrote a script for this case (LUKS + LVM) on an NVMe drive, but may expand it to /dev/sd* style drives as well. https://unix.stackexchange.com/a/467113/103652 — dragon788, Sep 05 '18 at 19:27

score 5 · Answer 4 · edited Dec 31 '18 at 14:39

For those here suffering from encryption-related problems, as in @Zanna's answer, you'll need to follow a procedure similar to this:

Boot into your system using a live distro / USB.
Mount the encrypted partition (in Ubuntu, you should see the encrypted volume available on the desktop; double-clicking and entering the password should suffice). The partition will be mounted at /media/ubuntu/[mount point]. (The username will change based on distro; e.g., Xubuntu uses xubuntu.)
Open a terminal window and a bourbon.

Set appropriate bindings for mount points within the system:

sudo su -
mount -t auto /dev/sdX /media/ubuntu/[mount point]/boot
mount --bind /dev /media/ubuntu/[mount point]/dev
mount --bind /dev/pts /media/ubuntu/[mount point]/dev/pts
mount --bind /sys /media/ubuntu/[mount point]/sys

chroot into the root directory of your encrypted disk: chroot /media/ubuntu/[mount point]
Ensure that your system has appropriate initramfs packages installed: sudo apt install cryptsetup-initramfs lvm2.
Critically, you'll also need to ensure that your configuration files force initramfs to include the cryptsetup binaries, which were removed at some point, it seems: nano /etc/cryptsetup-initramfs/conf-hook, uncomment the CRYPTSETUP line, and make sure it reads CRYPTSETUP=Y.
Finally, run update-initramfs -u -k all, shut down, pull the live media, and start back up.

Your mileage here may vary depending on what's happened with your system. If, for example, you've changed the LVM group name or the UUID, you may need to align /etc/crypttab and /etc/fstab to use the right identifiers. If, like me, you were migrating from one release to another, you may find that you have two encrypted volumes with the same group name—this makes mounting the disk rather difficult (you need to use the UUID explicitly).

All in all, the upgrade to Xubuntu 18.10 was awful because of this. (A stock system wouldn't reboot once the upgrades to the kernel were pulled in!) At least in the current setup I have, the system is stable through reboots.

N.b., the ACPI errors that led me all over the Internet looking for a solution were a red herring: they have no bearing on whether you can boot from an encrypted disk.

What is sdX in this case? When booting from a LiveCD, there is no /boot partition, so it is not clear what should go in there. — ralien, Apr 18 '19 at 13:16
@ralien — sdX is the drive holding the encrypted partition, probably sda in most systems. In my case, I encrypted the main disk (sda) during a fresh installation. — Ethan, Apr 18 '19 at 15:14

score 4 · Answer 5 · answered Jul 14 '20 at 16:08

4

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 settings was switched.

answered Jul 14 '20 at 16:08

KoenBal

169
1
2

I remember having to switch from RAID On to AHCI initially for something related to disk encryption when I first installed Ubuntu 20.04 so I should've thought of it. I had this same thing happen to me, and your answer solved it (thank you so much!!), how in the world did you figure it out? I'm on Dell Latitude. – fraiser Dec 07 '20 at 02:04
Worked on a Dell XPS 13 7390, running Ubuntu 20.04.3 LTS. It seems to switch to RAID upon very low power by itself (well there was a yellow, Support Assist warning screen I had to click "Continue" through, but still). Running Ubuntu from a flash drive on the machine didn't even show any other drives on it so I was really worried but this fixed everything perfectly. – zulu Sep 28 '21 at 11:26
Wow you are awesome. It worked :) None of the above answer matched for my Dell Optiplex Booting via LVM on 2TB nvme disk – privatejava Nov 20 '22 at 16:04

score 0 · Answer 6 · answered Jun 26 '22 at 15:28

0

My system couldn't boot after an update and wasn't prompting me to enter my LUKS passphrase for my root partition. However, I was able to boot after a manual unlock.

Note: Change /dev/vda3 to your root partition that contains Ubuntu.

(initramfs) cryptsetup luksOpen /dev/vda3 ubuntu
            Enter passphrase: *****
(initramfs) exit

The system boots.

answered Jun 26 '22 at 15:28

Wild Bear

1

I get 'sh: cryptsetup: not found' when I do this. – ohnoplus Jan 08 '23 at 20:14
1

@ohnoplus That's unfortunate. You don't have cryptsetup-initramfs package installed. This answer might be helpful for the case when the partition is encrypted only. – Wild Bear Jan 12 '23 at 23:04
Anyone have a permanent fix for this particular solution? – jewbix.cube Nov 29 '23 at 19:18

score 0 · Answer 7 · answered Aug 04 '22 at 13:49

0

Use boot-repair-disk

Download source: https://sourceforge.net/p/boot-repair-cd/home/Home/

I had the same problem, I solved it running an image with boot-repair-disk and less than 15 seconds it was solved. Try it.

answered Aug 04 '22 at 13:49

Victor Bernroider

1

score 0 · Answer 8 · edited Feb 20 '23 at 00:27

0

In my case, booting with the oldest kernel version available in the "Advanced options for Ubuntu" menu in Grub worked.

edited Feb 20 '23 at 00:27

QwertyChouskie

2,344
1
16
30

answered Jan 20 '23 at 11:26

Andrew_Dublin

111

1

duplicate of https://askubuntu.com/a/680886/94914 – karel Jan 21 '23 at 07:56

score 0 · Answer 9 · answered Oct 02 '15 at 19:06

0

Try the following:

(initramfs) reboot

Then, at the OS chooser prompt, try booting with an older kernel.

If you succeed, then probably this will fix the problem, as suggested in @One Face's bullets 4 and 5, and the link it refers:

sudo apt-get install lvm2

answered Oct 02 '15 at 19:06

e18r

259
8
11

If lvm2 not installed older kernel will not to boot. lvm2 package and kernel is not linked things. It need to boot with Rescue System and install package through chroot. – PRIHLOP Sep 12 '18 at 21:00

Gave up waiting for root device, ubuntu--vg-root doesnt exist

9 Answers9

unencrypt partition

Note: replace /dev/nvme0n1p3 with your disk

replace "nvme0n1p3_crypt" with the correct name

check by running this in chroot:

$ cat /etc/crypttab | cut -f1 -d " "

nvme0n1p3_crypt

mount root partition

prepare chroot environment

make dns available in chroot

enter chroot

re-install missing packages

re-generate (this might be done also by apt in the step before, I'm not sure)

Leave chroot environment - not sure if the following is really necessary...

Write buffers to disk

Unmount file systems

Linked

Related