Arch Linux

Vofan

Member

Registered: 2019-01-21

Posts: 65

Emergency shell from grub - lvm in luks. [SOLVED]

My partitions are:

sda1 1MB BIOS boot partition
sda2 luks
  vg0-swap 12G
  vg0-root ext4
sdb1 luks
  vg1-store ext4

Where /dev/mapper/vg0-root and .../vg0-store were mounted to /mnt and /mnt/store originally. I generated my fstab as genfstab -U /mnt /mnt/store. I do not know if this is best policy.
The exact message is:

ERROR: device '/dev/mapper/vg0-rot' not found. Skipping fsck.
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off

I have entered the passwords for both drives at this point - though both are remarkably slow.

I previously had to use this fix:

mkdir /mnt/hostlvm
mount --bind /run/lvm /mnt/hostlvm
arch-chroot /mnt
ln -s /hostlvm /run/lvm

For the udev error with lvm beforehand.

I tried https://unix.stackexchange.com/question … pping-fsck.

I am uncertain if I should have

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:luks0:allow-discards cyrptdevice=/dev/sdb1:luks1:allow-discards"

Specifically, whether it should just be luksØ or with just one of them in there. The partition scheme is GPT.

Thank you. There seems to be a lot of threads on the error message, but none have as yet seemed to be the same case upon expansion.

Last edited by Vofan (2019-01-28 11:25:26)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,427

Re: Emergency shell from grub - lvm in luks. [SOLVED]

You either have a lot of typos in your copying or a lot of typos in your actual files, neither are good baselines for properly fixing this.

The error is pretty clear, if it has really been properly copied (vg0-rot doesn't exist, vg0-root should though), and you might want to post your fstab. cyrptdevice doesn't make much sense but yes on the GRUB commandline you'd really only have to actively specify the one you intend to boot from.

You also shouldn't use /dev/sda and the like for partition identifiers as they tend to be unstable, but use UUIDs instead.

Vofan

Member

Registered: 2019-01-21

Posts: 65

Re: Emergency shell from grub - lvm in luks. [SOLVED]

You either have a lot of typos in your copying or a lot of typos in your actual files, neither are good baselines for properly fixing this.

The error is pretty clear, if it has really been properly copied (vg0-rot doesn't exist, vg0-root should though), and you might want to post your fstab. cyrptdevice doesn't make much sense but yes on the GRUB commandline you'd really only have to actively specify the one you intend to boot from.

You also shouldn't use /dev/sda and the like for partition identifiers as they tend to be unstable, but use UUIDs instead.

Both were typos, and both are what would be expected (vg0-root and cryptdevice). Sorry, at the time I felt that because the output was short it would be faster just to retype; I understand how that's bad practice for troubleshooting. I'll look into how to copy from some places I haven't worked out yet; I know how to paste shell output to pastebins/files.

My fstab is now:

# Static information about the filesystem.
# See fstab(5) for details.

# <File system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/vg0-root
UUID=1bd91d44-abb9-40d9-ab66-ec251a5a35c6    /           ext4        rw,relatime     0 1

# /dev/mapper/vg1-store
UUID=1f8788a2-fa28-458e-8aa3-78dda7a05188    /store      ext4        rw,relatime     0 2

# /dev/mapper/vg0-swap
UUID=3cc659a8-adf5-4433-94d9-03a40d9472f8    none        swap        defaults,pri=-2 0 0

# /dev/mapper/vg0-root UUID=1bd91d44-abb9-40d9-ab66-ec251a5a35c6
/dev/mapper/vg0-root     /           ext4        rw,relatime     0 1

# /dev/mapper/vg0-store UUID=1f8788a2-fa28-458e-8aa3-78dda7a05188
/dev/mapper/vg1-store    /store      ext4        rw,relatime     0 2

# /dev/mapper/vg0-swap UUID=8222cb4b-6225-4d3a-bda8-6dd159f4a3e4
/dev/mapper/vg0-swap     none        swap        defaults,pri=-2 0 0

When I run

$ grub-mkconfig -o /boot/grub/grub.cfg

now, it hangs.

loqs

Member

Registered: 2014-03-06

Posts: 19,104

Re: Emergency shell from grub - lvm in luks. [SOLVED]

When you are dropped to the rescue shell what is the output of

ls /dev/mapper/

When grub-mkconfig hangs what environment was it being executed from e.g. install media,  install media chroot,  emergency shell?

Vofan

Member

Registered: 2019-01-21

Posts: 65

Re: Emergency shell from grub - lvm in luks. [SOLVED]

When grub-mkconfig hangs what environment was it being executed from e.g. install media,  install media chroot,  emergency shell?

Install media chroot. It hangs both with

mkdir /mnt/hostlvm
mount --bind /run/lvm /mnt/hostlvm
arch-chroot /mnt
ln -s /hostlvm /run/lvm

done as an intermediate step and without it (I am unsure of the 'necessity' of doing the extra steps).

Ah! I waited long enough with the mkconfig running with the above lines during the chroot process, and we are back to

# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  WARNING: Device /dev/loop0 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: /dev/sda not initialized in udev database even after waiting 10000000 microseconds.
etc...

# ls /dev/mapper/
control   label       vg1-store

Bearing in mind that I haven't been able to run grub-mkconfig since changing the fstab and grub.cfg to follow UUIDs.

Last edited by Vofan (2019-01-26 23:39:35)

Vofan

Member

Registered: 2019-01-21

Posts: 65

Re: Emergency shell from grub - lvm in luks. [SOLVED]

I ran mkinitcpio and grub-mkconfig for the nth time and it worked, but it dumped me in an emergency shell after booting instead. I'm going to double check the current fstab and grub.cfg and reboot again, I'll post back with the errors or with whether I fixed this.

E: Nope.

Verifying DMI Pool Data ...............
GRUB GRUB GRUB GRUB GRUB GRUB

E: Tried a full reinstall. Same deal....

Last edited by Vofan (2019-01-28 04:51:33)

Vofan

Member

Registered: 2019-01-21

Posts: 65

Re: Emergency shell from grub - lvm in luks. [SOLVED]

From reading around, it seems that this would suggest either that the files are corrupted, or that the boot order is wrong in my BIOS. I don't understand how the former can be the case, and the latter Ihave checked.

I am assuming that fdisk -l would tell me if the partition scheme was for efi? The usb also doesn't find UEFI firmware, and to my knowledge the motherboard is an old model - I did have a degree of trouble identifying it through searches, and it looks like MBR/GPT to me.

Given the output of the usb though, I am guessing there is no conceivable way it can be UEFI? I may try just wiping again and reinstalling with grub-efi.

Failing that, I may have to try another distro on the machine (a long time ago, I did have an antergos install working fine on there as a dual-boot with windows, though I believe I didn't have LVM on LUKS, which appears to be the snag here, and I do remember having some problems with getting grub to notice arch), as my other machine's hardware problem is getting closer to the point of RIP, and I need at least one working for work.

Vofan

Member

Registered: 2019-01-21

Posts: 65

Re: Emergency shell from grub - lvm in luks. [SOLVED]

Well.. I fixed it and found the cause.

I would like to start by ways of an apology. This would have all been avoided, had I RTFM.

Please, if you remember and see me around, remind me to RTFM. Hopefully by RTFM I will learn enough to be of some use.

I don't know why grub wasn't recognising vg0-root originally, but I eventually reformatted and reinstalled grub, as I figured just reinstalling it if it was corrupted wouldn't cut it. That got me booting again, and after fiddling with my grub.cfg, I managed to get to emergency shell again (ie. vg0-root recognised). The culprit was, wouldn't you guess, /etc/crypttab. vg1-store wasn't being found, because I hand't told it that /dev/sdb1 was an an encrypted drive, and so got no prompt (or auto-unlock). So, having RTFM properly, the problem is resolved.

A huge thanks to all for trying to help.