Description of problem: Currently, grub2-install requires the option "GRUB_ENABLE_CRYPTODISK=y" to be enabled in /etc/default/grub for a successful installation when /boot is encrypted but the file /etc/default/grub in the grub2 package does not contain that option. By adding the option "GRUB_ENABLE_CRYPTODISK=y" to /etc/default/grub during installation, but before grub2 is setup, I was able to install Mageia5 beta1 successfully from both the net install and the DVD KDE install ISOs. I have successfully done several test installations with /boot encrypted on VirtualBox VMs, a laptop and on workstation. That said, there may be issues I have not encountered but from the GRUB2 code that uses GRUB_ENABLE_CRYPTODISK I think that non-encrypted /boot installations are unaffected by this options. As such, I propose adding the option "GRUB_ENABLE_CRYPTODISK=y" to /etc/default/grub and allow those interested in having a encrypted /boot to do so with minimal effort. There is one issue with this setup. The password must be entered twice, first for GRUB2 and second for cryptsetup in initrd. I will investigate a solution and if I find one I'll post another bug report. Next are details on one of the layouts I used for testing. # lsblk -o NAME,TYPE,FSTYPE,LABEL,MOUNTPOINT NAME TYPE FSTYPE LABEL MOUNTPOINT sda disk ââsda1 part crypto_LUKS ââcrypt_sda1 crypt LVM2_member ââMageia5-swap lvm swap Mageia5-swap [SWAP] ââMageia5-btrfs lvm btrfs Mageia5-btrfs / Version-Release number of selected component (if applicable): # rpm -q grub2 grub2-2.02-0.git9752.8.mga5 How reproducible: All times I tried. Steps to Reproduce: 1. Boot the systems from one of the ISO images (tested with DVD KDE and net boot ISOs). 2. Start a Mageia 5 installation. 3. Wait for the grub2 to be installed but don't before proceed with grub2 setup. 4. Add a line with "GRUB_ENABLE_CRYPTODISK=y" to /etc/default/grub . 5. Continue the installation, including grub2 setup, as usual. 6. Wait for installation to be completed. 7. Reboot the system. 8. GRUB2 should now show a password prompt. 9. Select "Mageia" on the GRUB2 menu. 10. Enter the password again. 11. Wait for the boot to complete. 12. Check that the system booted correctly. Reproducible: Steps to Reproduce:
assigning to maintainer for him to decide
CC: (none) => marja11Assignee: bugsquad => zen25000
CC: (none) => tmb
Any thoughts Thomas? I have asked upstream for comment. @marja: maintainer is nobody, so assigning back to default.
Assignee: zen25000 => bugsquad
I asked Jordan Uggla the following in #grub: "Does setting 'GRUB_CRYPTODISK_ENABLE=y' have any side effects on a non-encrypted install? See https://bugs.mageia.org/show_bug.cgi?id=14741" In reply to my query, he responded: "IIRC, it could lead to some normally unattended boots requiring a password at boot, for instance if there is a theme file stored in an encrypted volume, but the volume containing /boot/ and possibly even /root/ is unencrypted then without GRUB_CRYPTODISK_ENABLE=y grub-mkconfig would simply not have the grub.cfg refernence the theme as it's inaccesible and you could have unattended booting. With GRUB_CRYPTODISK_ENABLE=y the them is seen by grub-mkconfig as accessible, and so the theme is configured for use and the encrypted volume will be attempted to be unlocked by grub at boot, pausing indefinitely at a password prompt if nobody is there to enter the correct password or cancel. Indeed, see this mailing list post: http://lists.gnu.org/archive/html/grub-devel/2013-08/msg00065.html If you don't consider that to be a likely problem for your users (or less likely and severe than the problems caused by defaulting to 'n') then you may want to enable it by default but I wouldn't do so without first making another post on grub-devel asking about other possible problems. Also, as a lazy person who should do it myself, I ask that you please add an explanation for why GRUB_CRYPTODISK_ENABLE defaults to 'n' to grub.texi when you're through investigating :) As for their comment about being asked their password twice, I think you already know but that's a limitation caused by the linux boot protocol not having a secure way to pass along credentials from the bootloader. Some FreeBSD developers recently posted to grub-devel about adding support for passing on geli credentials to their kernel but I haven't seen any work on it from the linux front." We put themes in /boot/grub2 by default so I don't think it would cause an issue to set GRUB_CRYPTODISK_ENABLE=y for all installations, however I will ask on grub-devel list to check for other possible issues as Jordan suggested.
CC: (none) => zen25000
In reply to my query in grub-devel ML, Andrei Borzenkov replied: " The discussion happens every now and then. http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00112.html " All the files required by grub2 including fonts, themes and backgrounds are installed under /boot/grub2 so I don't think the proposed change will cause any regressions. I will push an updated grub2 package with this in the default config unless there are any objections in the next day or so.
CC: (none) => thierry.vignaud
On second thoughts maybe not. I found time to do some testing, and added it to the config on a system with no encryption at all. It causes an error message: error: device name required. this is triggered by this line which grub-mkconfig adds to grub.cfg: cryptomount -u it causes a "Press any key to continue" message. In practice the boot continues after about a 10 second delay without pressing a key. I have confirmed this in VM and real h/w. This is a regression that we certainly do not want to inflict on all users for the sake of a corner case. I have reported the above on the grub-devel ML.
OK upstream has fixed the regression with a patch for grub-mkconfig_lib.in It tests OK here so I will push an updated patched package with 'GRUB_CRYPTODISK_ENABLE=y' Closing as fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Barry Jackson from comment #6) > OK upstream has fixed the regression with a patch for grub-mkconfig_lib.in > > It tests OK here so I will push an updated patched package with > 'GRUB_CRYPTODISK_ENABLE=y' > > Closing as fixed. Thanks a lot, Barry! @ docteam @ QA team When GRUB2 is chosen as bootloader, having an encrypted /boot is now possible. However, maybe this needs to be tested with the 5beta2 isos before updating our documentation (if any one finds time to do that): http://doc.mageia.org/installer/4/en/content/diskdrake.html (The *Warning* on that page) @ barjac This is only for GRUB2 and won't work for grub2-efi, correct?
CC: (none) => doc-bugs, qa-bugs
(In reply to Marja van Waes from comment #7) > @ barjac > This is only for GRUB2 and won't work for grub2-efi, correct? I guess that's what secure boot is for with a UEFI systems so maybe not needed. Not something I can test here, but certainly the variables in /etc/default/grub are equally accessible to grub2-efi, so I'm not sure.
(In reply to Marja van Waes from comment #7) > before updating our documentation (if any one finds time to do that): > http://doc.mageia.org/installer/4/en/content/diskdrake.html (The *Warning* > on that page) Sorry to hijack this one, but related: When you update the partitioning / bootloader documentation, would be nice if someone could add a hint, that when using / with btrfs filesystem, automatically grub2 will be chosen. (Not sure if that also applies to /boot as btrfs though) /me was just curious and installed his new box choosing btrfs for everything, and it worked flawlessly :)
CC: (none) => doktor5000
*** Bug 14626 has been marked as a duplicate of this bug. ***