Score:0

22.04 (LVM, encrypted) stopped booting, drop to shell: Error: vgubuntu-root does not exist

pf flag

I'm running Ubuntu 22.04 with LVM/encryption. This morning, the normal boot sequence stopped working: it does not prompt me for my encryption password, but instead drops to a shell with the following error: ALERT! /dev/mapper/vgubuntu-root does not exist. Dropping to a shell!

I found a similar problem a while ago at Error: vgubuntu-root does not exist. Dropping to a shell

The workaround suggested there (manually decrypting the drive from the shell prompt) does work, but is not persistent. (Note also that it goes to the normal prompt asking that the drive be decrypted a second time.)

I'm guessing something changed (due to an update?) which made grub skip the drive decrypting step, but no permanent solution is suggested in the linked question. I've tried recreating grub using update-grub and grub-repair, with no success. Anyone know how I can get my old boot sequence back?

Additional: Per suggestion below, I tried booting to an older kernel; no luck. Available kernels are 5.15.0-43, -58, and -60. In all three cases, I am dropped into the shell before being asked for the encryption password.

ar flag
It maybe a bug. [See the bug report](https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1986623). To test, boot to the previous kernel [as suggested in the bug report's comment 7](https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1986623/comments/7). Then update the question.
Gary avatar
pf flag
No luck; see edit above.
Gary avatar
pf flag
Just did a fresh install on a spare hard drive, and it boots fine. Will next try reinstalling on my main drive.
Gary avatar
pf flag
Seems to be fine after reinstall. Keeping my fingers crossed this won't recur.
Gary avatar
pf flag
No luck. Worked fine until I downloaded some updates this morning, then the problem recurred. Not sure exactly what was updated, since /var/log/dpkg.log doesn't seem to be human-readable.
Gary avatar
pf flag
I would love to upvote user68186's comment, but don't see the up-arrow button to do so.
ar flag
Thanks! Your question does not mention you copied / cloned the system files from another computer! So the problem was not updates but your own action. I (or anyone else) could have never figured that out.
Gary avatar
pf flag
Indeed. Had I realized that was a relevant fact I would have mentioned it, but the fact that the system worked fine prior to the update made me mistakenly think it wasn't related. Hopefully, my answer will help someone who has a similar problem someday.
ar flag
For the answer to be helpful, you will have to substantially revise the question. Now that you know what not to do, and more importantly what to do, you may want to ask a new question how to properly do what you did and then answer that question. I am voting to close this question as the problem is not reproducible.
Gary avatar
pf flag
I'm open to suggestions re: how to revise, but it seems to me that someone else with a similar problem is going to be searching for the symptoms (stopped asking to decrypt drive, dropped to shell) rather than the cause.
Score:0
pf flag

Thanks to everyone who provided pointers to similar problems I was able to track this down. The problem was fixed by simply updating /etc/crypttab.

My encrypted partition is on sda3, but because I copied data from a prior configuration with a different partition scheme, my /etc/crypttab looked like this:

sda6_crypt UUID={uuid] none luks,discard

It appears that when the initramfs image is generated (as when a new kernel is installed, but also on other updates), a mismatch between the naming in /etc/crypttab and the actual partition causes an error (which of course I didn't see) such that the file in the initramfs (located at /cryptroot/crypttab) was empty (zero bytes). This lack of a file is what causes the boot process to hang. Correcting /etc/crypttab to:

sda3_crypt UUID={uuid} none luks,discard

solves the problem. Of course, if your initramfs is already honked it needs to be regenerated:

sudo update-initramfs -u

But future updates should proceed normally.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.