Feature changed by: Michael Chang (michael-chang) Feature #315499, revision 20 Title: decide whether ESP (EFI system Partition) is to be used as /boot openSUSE Distribution: New Priority Requester: Mandatory Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: There needs to be a decision about how to proceed wrt /boot. Citing https://bugzilla.novell.com/show_bug.cgi?id=808017#c7 Looks like there are different opinions about what is the best setup. For reference, here is a discussion on the systemd list which indicates that they plan to mount the ESP at /boot: http://lists.freedesktop.org/archives/systemd-devel/2013-January/008273.html AFAICT there are several proposals so far: 1) ESP at /boot/efi, separate /boot as usual, only bootloader in ESP 2) ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader implements all features to access raid, lvm, crypto etc. itself. 3) ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader setup script copies kernel&initrd to ESP. 4) ESP at /boot, bootloader (optional), kernel and initrd in ESP. kernel&initrd would need to be packaged in e.g. /boot/EFI/opensuse then. 1. and 2. require feature rich bootloaders like grub2 while 3 and 4 don't. Discussion: #1: Ludwig Nussel (lnussel) (2013-07-03 09:18:03) Note, please do not add private comments as this affects openSUSE and the decision needs to be transparent. Note the Feature freeze for openSUSE is in August and the last Beta in September so we should have the final solution implemented ASAP. #2: Michael Chang (michael-chang) (2013-07-08 09:11:21) My opinion is default to #2 and if bootloader (grub2) can't support then we fallback to #1. That way we can deal with all architectures consistently (In kernel/bootloader installation and in proposing system partition layout) For #3 (or even #4) we have to introduce new bootloader as long as grub2 is not preferred, and implement distinguished procedure for installing kernel etc. If we don't care about the extra maintaining prospects in UEFI mode, I'm fine with it. For #4 .. I don't see any merit of it ?? #3: Michael Chang (michael-chang) (2013-07-08 09:21:45) Btw, if we want to fully utilize the functionality of lvm, mdadm and/or btrfs, we'd better go #2. Others are sub-optimal as long as kernel, initrd or boot config cannot be managed by those technologies. #4: Neil Rickert (nrickert) (2013-07-19 22:22:06) None of the above. I'll first comment on the options offered. Of those, I prefer #2, if it can be done properly. And otherwise #1. For #2 to be done properly would require that with an encrypted LVM, the encryption key is only requested once. If we have to give the key to grub, then later give it again to the booting system, that is not satisfactory. The biggest problem for #3 and #4, is that they want to put the kernel and initrd into the ESP. If you have multiple kernels and are using plymouth, that might be 45M per kernel. The ESP is supposed to shared with other operating systems. We should not clutter it up with what will be part of the running opensuse system. My own preference would be to separate the boot-manager function from the os-loader function. Only the boot-manager would go in the ESP, together with control info about the operating systems it could load. The os-loader would be part of the opensuse partitions. The boot- manager would be intended to run stand-alone and boot multiple systems. An opensuse install would register itself with an existing boot manager, or optionally install or reinstall that boot manager. This would take some software development, so I don't expect it to happen soon. #10: Michael Chang (michael-chang) (2013-08-27 08:36:58) (reply to #4) The boot manager like refind is good, and I believe the default loader path (\EFI\BOOT\BOOTX64.EFI) is perfect for him, but still there's some limitation imposed by lacking of UEFI drivers to read the files, be it os loader or kernel, on certain file system and block devices (like lvm, mdadm ..). The means separated /boot is sometimes necessary in order to boot. #8: Ludwig Nussel (lnussel) (2013-08-23 11:07:56) There seems to be a preference on #2. Unfortunately we are running out of time for openSUSE though. How are chances that we get grub2 to be able to unlock luks and read LVM and RAID within the next two weeks? If that cannot be made to work before Beta1 we need the change in the partitioner to go for #1. #9: Michael Chang (michael-chang) (2013-08-27 08:14:18) (reply to #8) In order to boot from encrypted partition, we need to set GRUB_CRYPTODISK_ENABLE=y in perl-bootloader when invoking grub2-install and grub2-mkconfig. Besides yast2 storage doesn't allow any attempt to set /boot or /root encrypted so we have to remove the restriction when grub2 is in use. #11: Jiri Srain (jsrain) (2013-08-27 08:40:18) (reply to #8) Well, I admit I have never tried openSUSE in uEFI environments, but AFAIR from IA64, the elilo bootloader's installer copies the kernel and initrd to the EFI partition. If, from any reason, GRUB2 cannot access the kernel and initrd in the root partition, could the installer also copy them to the EFI partition? + #12: Michael Chang (michael-chang) (2013-08-27 09:47:33) (reply to + #11) + Jiri, did you mean #1 vs. #3 as fallback of #2 ? I prefer #3 than #1 is + because it can be more consistent across firmware and architectures. #3 + is anyhow firmware specific .. -- openSUSE Feature: https://features.opensuse.org/315499