Created attachment 1395147 [details] System complaining about /boot being on encrypted block device Description of problem: As whomever reads this may know, since the bootloader is installed in the ESP along with its configuration, /boot can be encrypted. GRUB_ENABLE_CRYPTODISK=y simply needs to be in /etc/default/grub (of the target system) when GRUB generates its configuration for this to work. Unless there is something I don't realize preventing this from being a valid setup with anaconda, I don't see why this couldn't be implemented. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Boot up installer media 2. Select language 3. Go to 'Installation Destination' 4. Make sure a disk is selected to install to 5. Select 'Advanced Custom (Blivet-gui)' 6. Press the 'Done' button 7. Create EFI System Partition (ESP) and set mount-point /boot/efi 8. Create LVM2 Volume Group and select 'encrypted' (set a passphrase) 9. Go over to freshly created VG and create a root and swap logical volume 10. Press 'Done' once again, this will create a warning at the bottom of the screen 11. (optional) click warning to see that system complains that you can't have /boot on an encrypted block device 12. (if pop-up opened, press close) Press 'Done' once again. 13. Press 'Accept Changes' 14.a. Install will not progress beyond this point. 14.b. If no bootloader is chosen to be installed, go on and attempt to install system as normal. Actual results: 1. If you choose not to install a bootloader, the install will go on, but try to install GRUB anyway (a bug in and of itself), and will fail, which causes the whole installation to fail and the system to shutdown. 2. if bootloader is chosen to be installed, install can not go on, as the system complains /boot is on an encrypted block device. Expected results: GRUB installs successfully and install goes on as usual. Additional info:
Hello Peter, Could you please verify that we can safely add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub and it will work? Or do we need some bigger changes? Thank you, Jirka
(In reply to Jiri Konecny from comment #1) > Hello Peter, > > Could you please verify that we can safely add GRUB_ENABLE_CRYPTODISK=y to > /etc/default/grub and it will work? Or do we need some bigger changes? > > Thank you, > Jirka FWIW I've been using something like this for a long time (on a non-EFI boot setup): https://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/
I see this bug has been labelled [NEEDINFO], what information is required?
I am aware of several issues. 1. The necessary grub modules (cryptodisk and luks + modules for the algorithms chosen) must be available, but it is almost guaranteed that they are not. The package 'grub2-efi-x64-modules' is not installed by default and the modules it contains aren't transferred to /boot/efi/EFI/fedora/x86_64-efi/ even if/when it is installed. Additionally, on a system with secure boot enabled (which is quite likely on the UEFI platform), none of that matters anyway because grub modules cannot be inserted whatsoever. The ones contained inside grubx64.efi are loaded on boot, but not again. This point would be resolved by https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2 2. Not exactly an issue per se, but grub is incompatible with LUKS2. Anaconda would need to enforce this, inform users, etc. 3. Jiri Konecny, if you're configuring this for yourself, after install, you will also need to add an entry to /etc/crypttab and then regenerate your grub.cfg and initramfs. As stated earlier, use LUKS1 for /boot and the relevant grub modules must also be available. Anaconda will write crypttab entries, so that isn't an issue here (I think? To my knowledge, anaconda writes system-dependent config files, etc, based on what was done in previous steps). 4. Some considerations: Perhaps set a lower iter-time for /boot? Grub's decryption is slower than the kernel's, and cryptsetup sets the iteration count based on the system it's running on. Grub will take longer than cryptsetup plans for/deems reasonable (2000ms is the default). In addition, if the root partition is encrypted, the user could be asked for up to 3 passwords (grub asks for /boot, then the kernel asks for / and /boot). If they're encrypting both root and boot (and home, but sometimes that's in an lvm with root), we should advise users to consider setting the same password. I hope this helps.
This is how I do it ... https://bugzilla.redhat.com/show_bug.cgi?id=1615167#c1 It's an UEFI install of an encrypted lvm on /dev/sda1 & raw /boot on /dev/sda2 (so I can remove /dev/sda2 later). GPTs initially looks like this: sda1 fat16/efi sda2 lvm/luks sda3 raw/xfs Post-boot, doing this ... umount /boot/efi && mkdir -p /mnt/sysimage && mount -B / /mnt/sysimage rsync -avp /boot/ /mnt/sysimage/boot/ umount /boot mount /boot/efi sed -i '/[[:space:]]\/boot[[:space:]]/s/^/#/g' /etc/fstab dnf remove grub2-efi-x64 dnf install grub2-efi-x64-modules echo GRUB_ENABLE_CRYPTODISK=y >> /etc/default/grub # more grub stuff grub2-mkconfig -o /boot/grub2/grub.cfg grub2-install parted /dev/sda rm 3 systemctl reboot I end up with this, and it's bootable, which is the goal ... sda1 fat16/efi (without a grub.cfg) sda2 lvm/luks I'd like to be able to do something similar in preinstall via anaconda/kickstart but there's nothing in /usr/lib/grub at that point. I'm waiting for this .. https://bugzilla.redhat.com/show_bug.cgi?id=1722938 Most of the issues seem to stem from the custom grubx64.efi, which tends to break. I'd rather use the one that grub2-install builds and not have to worry that an update or reinstall is going to affect it.
I'd love to see anaconda allowing an encrypted boot partition. I don't believe anaconda has to provide a GUI way of encrypting the boot block device, but allowing the user to encrypt it manually over the command line from the anaconda installer before installation does seem reasonable. (In reply to Benjamin from comment #4) > ... > 4. Some considerations: Perhaps set a lower iter-time for /boot? Grub's > decryption is slower than the kernel's, and cryptsetup sets the iteration > count based on the system it's running on. Grub will take longer than > cryptsetup plans for/deems reasonable (2000ms is the default). In addition, > if the root partition is encrypted, the user could be asked for up to 3 > passwords (grub asks for /boot, then the kernel asks for / and /boot). If > they're encrypting both root and boot (and home, but sometimes that's in an > lvm with root), we should advise users to consider setting the same password. If the user is advanced enough to want to encrypt the boot partition (manually over the command line), he'll also be able to choose the iter-time and password himself. In my opinion, an installer like anaconda shouldn't restrict the user in that manner.
Echoing most of #c4... would also prefer not to increase workload on grub at this time.
There's a patch that allows this install to work: https://github.com/chenxiaolong/fedora-encrypted-boot It also handles 2 of c4 (ensure that LUKS1 is used). FWIW: I tried installing multiple Linux distributions this week with the following setup: * 1G ESP fat /boot/efi * rest LUKS ext4 / And it's really interesting: * Ubuntu fails with almost the exact same message as Fedora. * But it's the default for Lubuntu (when enabling encryption). * Debian fails with almost the exact same message as Fedora. * But it's the default when booting from a live image instead of using the installer (when enabling encryption). * It's the default for openSUSE (when enabling encryption).