You are not logged in.
I installed Arch Linux on 3 different computers with full disk encryption, including the Boot partition.
Specifications:
1) i5 - 9th gen; Samsung EVO 970
/dev/nvme0n1p1 - efi, /dev/nvme0n1p2 - encrypted boot, /dev/nvme0n1p3 - encrypted lvm
2) i7 - 11th gen; Samsung EVO 970
/dev/nvme0n1p1 - efi, /dev/nvme0n1p2 - encrypted boot, /dev/nvme0n1p3 - encrypted lvm
3) i3 - 4th gen; Seagate HDD 1TB (5400 rpm)
/dev/sda1 - efi, /dev/sda2 - encrypted boot, /dev/sda3 - encrypted lvm
In all three cases EFI partition is mounted in /boot/efi directory, I have encrypted the BOOT partition with luks1 type and the third partition is encrypted with luks2 type and there is LVM group with 2 logical partitions, root and home. I'm not using swap.
To avoid having to enter encrypted partition passwords twice, I use the keyfile. As a result, I only have to type the BOOT partition password.
GRUB_CMDLINE_LINUX I have specified cryptdevice=UUID=XXX ........ XXX):cryptdrive root=/dev/mapper/vgdrive-root
(cryptdrive is PV's name, vgdrive - volume group's name)
The problem is:
On two computers running SSD, after entering the BOOT password, the system crashes into the Emergency Shell with a well-known error:
ERROR: device '/dev/mapper/vgdrive-root' 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
This problem is not on the computer where standard laptop HDD is used. Now I am posting from this computer. The standard way of solving this problem doesn't work in my case. I don't know blame the SSD firmware or anything else, the fact is that I installed Arch about 15 times this week with full disk encryption and on computers where nvme drive is in all cases this problem occurred and not fixed, but on computer where HDD is used there is no any problem. Installation is similar on all three computers.
I used this install manual other_site
For testing I also installed Fedora on that SSD with automated install. It doesn't encrypts /boot, only encrypts root volume and this works in my case.
So, what you think, is this SSD's firmware bug? I think it's problematic use two different encrypted volume on this type of SSD. I tried to many fixing way, wich is maked as [SOLVED] and none of them worked for me.
Last edited by spillet1 (2021-07-02 10:49:50)
Offline
Have you tried adding MODULES=(nvme ...) to your /etc/mkinitcpio.conf on the affected systems?
Last edited by Taijian (2021-07-02 10:00:33)
Offline
I don't use nvme drives myself, but I've seen plenty of posts here where adding the --removable flag to the grub-install command helps.
Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.
Offline
Have you tried adding MODULES=(nvme ...) to your /etc/mkinitcpio.conf on the affected systems?
Just after I read your answer, I add vmd in MODULES and nvme_load=yes as Kernel parameter and problem gone.
Thanks.
Last edited by spillet1 (2021-07-02 10:50:19)
Offline