Feature changed by: Ludwig Nussel (lnussel) Feature #315499, revision 16 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. + #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. -- openSUSE Feature: https://features.opensuse.org/315499