| View previous topic :: View next topic |
| Author |
Message |
nxe9
Tux's lil' helper
Joined: 05 Jun 2021
Posts: 116
|
 Posted: Mon Oct 21, 2024 9:32 pm Post subject: Encrypted root partition: Invalid passphrase, Grub and LUKS2 |
 |
|
Hi, I'm trying to install gentoo with an encrypted partition. During startup, a password prompt appears and after entering the correct password, the follow error appears.
| Code: | Enter passphrase for hd0,gpt2 (<uuid>):
error: Invalid passphrase
error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded.
error: disk `lvmid/<...>' not found.
Entering rescue mode...
grub rescue> |
I have read the following thread and realize that it is probably related to LUKS2 and PBKDF: argon2id.
https://forums.gentoo.org/viewtopic-p-8819261.html
User @sMueggli also brought this to my attention in another thread, and I also found this information on another forum.
https://forums.gentoo.org/viewtopic-p-8843694.html#8843694
https://bbs.archlinux.org/viewtopic.php?pid=2160962#p2160962
However, before I try to solve the problem, I wanted to describe what I actually do and how I understand the boot process and steps to prepare the boot process. I probably don't understand everything yet, so I would like to compare my knowledge and make sure that my approach makes sense. Let me start by saying that I have two machines that have Gentoo encrypted. The first system (pc1) works without any problems and it was configured some time ago. I'm trying to install the second system (pc2).
@pietinger Recently I read some of your posts, which allowed me to better understand what happens when the system boots. Thanks for this.
pc1:
I will ignore additional irrelevant partitions for simplicity.
| Code: | - sda1: no encryption, vfat, mounted on /boot, contains EFI/BOOT/BOOTX64.EFI and grub/ with some grub files
- sda2: lvm (pvcreate - lvm, vgcreate - vg0, lvcreate - root)
-- root |
Build-in kernel command line:
| Code: | | (dolvm crypt_root=PARTUUID=<...> root=/dev/mapper/vg0-root) build in kernel command string |
initramfs creation using genkernel:
| Code: | mkdir /tmp/initramfs
cd /tmp/initramfs
cp /usr/src/linux/.config .
genkernel --luks --lvm --kernel-config=.config initramfs |
grub install
| Code: | | grub-install --target=x86_64-efi --efi-directory=/boot --removable |
grub config
| Code: | | grub-mkconfig -o /boot/grub/grub.cfg |
So the following things happen:
1. 'make install' copies the kernel to /boot
2. 'genkernel...' creates initramfs and will copy it to /boot, which will allow initramfs to prepare the root partition during boot
3. 'grub-install...' installs grub to the sda1 device. More specifically, it will create a bootx64.efi binary that will be loaded during boot and some grub files inside /boot/grub/..
4. 'grub-mkconfig...' will create a configuration file that will allow to find and load the kernel and initramfs during boot
What happens while booting?
1. Firmware / UEFI looks for BOOTX64.EFI binary (grub binary) and loads it.
2. Grub binary loads the kernel
3. Kernel starts initramfs
4. Initramfs asks for a password and mounts the encrypted root partition
Did I understand it correctly? There are two questions from me about this.
1. Why doesn't the error I mentioned at the beginning, the one on PC2, appear here? Because in this case grub doesn't have to decrypt anything. Decryption only happens in initramfs without the involvement of grub. True?
2. What about the build-in kernel command line (dolvm crypt_root=PARTUUID=<...> root=/dev/mapper/vg0-root)? Does the kernel calls it before loading initfams so that initramfs can access the lvm container?
Now let's move on to pc2. My idea was to use the /efi partition instead of /boot, because that's how it was described in the handbook and prepare booting using dracut and new tools such as makeinstall with the dracut flag.
pc2:
it's actually nvme instead of sda, but that's not important.
| Code: | - sda1: no encryption, vfat, mounted on /efi, contains EFI/BOOT/BOOTX64.EFI
- sda2: lvm (pvcreate - lvm, vgcreate - vg0, lvcreate - root)
-- root, contains /boot/grub |
Build-in kernel command line:
| Code: | | root=UUID=<...> rd.luks.uuid=<...> rd.lvm.vg=vg0 |
package.use, because 'make install' should generate dracut initramfs
| Code: | | sys-kernel/installkernel dracut |
/etc/dracut.conf
| Code: | | add_dracutmodules+=" crypt dm rootfs-block lvm " |
/etc/default/grub, because /boot is on crypted root.
| Code: | | GRUB_ENABLE_CRYPTODISK=y |
grub install
| Code: | | grub-install --efi-directory=/efi |
grub config
| Code: | | grub-mkconfig -o /boot/grub/grub.cfg |
So the following things happen:
1. 'make install' copies the kernel to /boot, creates initramfs with dracut and copy it to /boot
2. 'grub-install...' installs grub to the sda1 device (/efi) and sda2 (/boot). More specifically, it will create a bootx64.efi binary inside /efi that will be loaded during boot and some grub files inside /boot/grub/.
4. 'grub-mkconfig...' will create a configuration file inside /boot/grub that will allow to find and load the kernel and initramfs during boot
What happens while booting?
1. Firmware / UEFI looks for BOOTX64.EFI binary (grub binary) and loads it.
2. Grub binary wants to access the kernel inside root/boot and needs to encrypt the /root partition. A password prompt appears and in my case the encryption fails because grub cannot decrypt LUKS2.
3. Grub binary loads kernel from /root/boot
4. Kernel starts initramfs
5. Initramfs asks for a password and mounts the encrypted root partition
Have I understood this process correctly? If so, now let's move on to the solution. One solution is luks1. However, I don't really see the advantage of keeping /boot on an encrypted partition. What is the main advantage? That no one with physical access to the disk will be able to view my kernel, right? Do I understand correctly that in this case I will have to enter the password twice, or maybe grub will be able to pass the decrypted partition to initramfs?
Thank you very much if anyone made it to the end and would like to share their knowledge with me. |
|
| Back to top |
|
 |
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 497
|
| Posted: Tue Oct 22, 2024 9:19 am Post subject: |
|
|
More or less your understanding is correct.
Some notes to Grub:
On PC1 you are using "grub-install ... --removable". This will place the Grub EFI binary on the ESP under EFI\BOOT\BOOTX64.efi. That is a special location and other bootloaders can overwrite it (if you only have one bootloader, it's not a big problem).
On PC2 you are using "grub-install --efi-directory=/efi". This will place the Grub EFI binary on the ESP under EFI\gentoo\grubx64.efi. That is safer as other bootloaders (apart from "Gentoo bootloaders) will not overwrite this binary.
Long story short: You should not use the "--removable" option on grub-install.
Some notes on encrypted /boot:
Disadvantage: Grub takes some time to unlock the LUKS container (Grub is quite slow) and the initramfs needs to unlock the same container again.
Advantages: With an encrypted initramfs you can place a key file inside to automatically unlock the LUKS container (you only need to enter the passphrase once).
Others can not replace your kernel, initramfs, grub.cfg.
On binary distributions such as Fedora you could have an unencrypted /boot and use Secure Boot to "secure" your system. Binary distros are building and signing the relevant parts and the chain of trust should be intact and guarantee that the files were not tampered. The distribution is responsible for the correct process.
Of course you can also use Secure Boot on source-based distributions. But, in my opinion, a do-it-yourself-secure-boot is hard to achieve. A working "Secure Boot" is not necessarily a secure "Secure Boot" and I call it a "Signed Boot".
And finally you can also use LUKS2 with an encrypted /boot if you change the PBKDF. |
|
| Back to top |
|
|
nxe9
Tux's lil' helper
Joined: 05 Jun 2021
Posts: 116
|
| Posted: Thu Oct 24, 2024 5:17 pm Post subject: |
|
|
Thanks. Some additional questions.
| sMueggli wrote: | | Advantages: With an encrypted initramfs you can place a key file inside to automatically unlock the LUKS container (you only need to enter the passphrase once). |
Can I do it automatically using dracut? Or do I have to create my own initramfs?
In the case of an encrypted /boot, how does grub know which partition to decrypt? I was surprised that in this situation the UUID of my root partition was shown in the terminal, which means that Grub detected it correctly. But how does he know about this partition and how does he know about lvm? Is this somehow written automatically to the grub binary when grub-install is invoked? |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 497
|
| Posted: Fri Oct 25, 2024 9:46 am Post subject: |
|
|
| nxe9 wrote: | | sMueggli wrote: | | Advantages: With an encrypted initramfs you can place a key file inside to automatically unlock the LUKS container (you only need to enter the passphrase once). |
Can I do it automatically using dracut? Or do I have to create my own initramfs? |
I never tried it with Dracut and I never found the time to try it myself. I know it works for Arch Linux and also Ubuntu, but they do not use Dracut. With Fedora I usually have an unencrypted /boot partition and rely on Secure Boot.
My approach would be to put the key file into the intitramfs with the dracut config: | Code: | | install_items+="/etc/luks.key" |
.
And then append "rd.luks.key=/etc/luks.key" to the kernel command line. Please see also "man 7 dracut.kernel" for more details. The man page also mention a problem with systemd. I am not sure, whether this problem with the systemd-cryptsetup-generator is still present or solved meanwhile.
| nxe9 wrote: | | In the case of an encrypted /boot, how does grub know which partition to decrypt? I was surprised that in this situation the UUID of my root partition was shown in the terminal, which means that Grub detected it correctly. But how does he know about this partition and how does he know about lvm? Is this somehow written automatically to the grub binary when grub-install is invoked? |
I am not sure. But I think when you call grub-install, Grub has enough informations. And yes, a "strings grubx64.efi" reveals that the binary contains a string with the location of the .../boot/grub directory. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
