Feature changed by: Michael Chang (michael-chang) Feature #315499, revision 5 Title: decide whether ESP is to be used as /boot openSUSE Distribution: Unconfirmed 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 ?? -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Neil Rickert (nrickert) Feature #315499, revision 8 Title: decide whether ESP is to be used as /boot openSUSE Distribution: Unconfirmed 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. -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Andreas Jaeger (a_jaeger) Feature #315499, revision 14 Title: decide whether ESP (EFI system Partition) is to be used as /boot - openSUSE Distribution: Unconfirmed + 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. -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Michael Chang (michael-chang) Feature #315499, revision 17 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. + #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. -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Jiri Srain (jsrain) Feature #315499, revision 19 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? -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Jiri Srain (jsrain) Feature #315499, revision 21 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 .. + #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) + Yes, #3 IMO better describes what SLES11 and ELILO do. -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Jiri Srain (jsrain) Feature #315499, revision 23 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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). + #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) + Michael, remember that we will need to support SLES11 machines upgraded + to SLES12) - and there you cannot create another partition during the + update process. -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Michael Chang (michael-chang) Feature #315499, revision 25 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. #16: Michael Chang (michael-chang) (2013-08-27 13:01:35) (reply to #9) Just finished quick test on 13.1 for grub2 to boot from luks encrypted partition, it works for me with a small glitch that theme file not found (should be rather easy to fix ..). Provide my steps here for reference. cryptsetup luksFormat /dev/vda2 cryptsetup luksOpen /dev/vda2 cr_boot mkfs.ext3 /dev/mapper/cr_boot mount -t ext3 /dev/mapper/cr_boot /mnt cp -a /boot/* /mnt/ umount /mnt mount /dev/mapper/cr_boot /boot GRUB_CRYPTODISK_ENABLE=y grub2-install /dev/vda GRUB_CRYPTODISK_ENABLE=y grub2-mkconfig -o /boot/grub2/grub. cfg And edit /etc/crypttab, /etc/fstab to use new /boot, reboot and grub2 will ask you to provide paraphrase to unlock encrypted /boot and once again in systemd. #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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) Michael, remember that we will need to support SLES11 machines upgraded to SLES12) - and there you cannot create another partition during the update process. + #17: Michael Chang (michael-chang) (2013-08-27 13:08:16) (reply to + #15) + Yes that's very good point .. :) -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Steffen Winterfeldt (snwint) Feature #315499, revision 29 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. #16: Michael Chang (michael-chang) (2013-08-27 13:01:35) (reply to #9) Just finished quick test on 13.1 for grub2 to boot from luks encrypted partition, it works for me with a small glitch that theme file not found (should be rather easy to fix ..). Provide my steps here for reference. cryptsetup luksFormat /dev/vda2 cryptsetup luksOpen /dev/vda2 cr_boot mkfs.ext3 /dev/mapper/cr_boot mount -t ext3 /dev/mapper/cr_boot /mnt cp -a /boot/* /mnt/ umount /mnt mount /dev/mapper/cr_boot /boot GRUB_CRYPTODISK_ENABLE=y grub2-install /dev/vda GRUB_CRYPTODISK_ENABLE=y grub2-mkconfig -o /boot/grub2/grub. cfg And edit /etc/crypttab, /etc/fstab to use new /boot, reboot and grub2 will ask you to provide paraphrase to unlock encrypted /boot and once again in systemd. #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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) Michael, remember that we will need to support SLES11 machines upgraded to SLES12) - and there you cannot create another partition during the update process. #17: Michael Chang (michael-chang) (2013-08-27 13:08:16) (reply to #15) Yes that's very good point .. :) #18: Lukas Ocilka (locilka) (2013-09-05 16:49:18) (reply to #8) Steffen, could you, PLS, evaluate the current development status vs. proposed solution #2 in description? Is that possible? + #19: Steffen Winterfeldt (snwint) (2014-01-22 16:47:56) + Well, it seems what we have now is #2 (at least on x86) with a + /boot/grub2/x86_64-efi subvolume while we will have to deal with #3 in + the update case. Michael, is that correct? What is supposed to happen + during an update? Keep elilo? And from sle11-sp3? Keep the grub2 config + with #3? Do we support updates via 'zypper dup'? -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Steffen Winterfeldt (snwint) Feature #315499, revision 31 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. #16: Michael Chang (michael-chang) (2013-08-27 13:01:35) (reply to #9) Just finished quick test on 13.1 for grub2 to boot from luks encrypted partition, it works for me with a small glitch that theme file not found (should be rather easy to fix ..). Provide my steps here for reference. cryptsetup luksFormat /dev/vda2 cryptsetup luksOpen /dev/vda2 cr_boot mkfs.ext3 /dev/mapper/cr_boot mount -t ext3 /dev/mapper/cr_boot /mnt cp -a /boot/* /mnt/ umount /mnt mount /dev/mapper/cr_boot /boot GRUB_CRYPTODISK_ENABLE=y grub2-install /dev/vda GRUB_CRYPTODISK_ENABLE=y grub2-mkconfig -o /boot/grub2/grub. cfg And edit /etc/crypttab, /etc/fstab to use new /boot, reboot and grub2 will ask you to provide paraphrase to unlock encrypted /boot and once again in systemd. #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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) Michael, remember that we will need to support SLES11 machines upgraded to SLES12) - and there you cannot create another partition during the update process. #17: Michael Chang (michael-chang) (2013-08-27 13:08:16) (reply to #15) Yes that's very good point .. :) #18: Lukas Ocilka (locilka) (2013-09-05 16:49:18) (reply to #8) Steffen, could you, PLS, evaluate the current development status vs. proposed solution #2 in description? Is that possible? #19: Steffen Winterfeldt (snwint) (2014-01-22 16:47:56) Well, it seems what we have now is #2 (at least on x86) with a /boot/grub2/x86_64-efi subvolume while we will have to deal with #3 in the update case. Michael, is that correct? What is supposed to happen during an update? Keep elilo? And from sle11-sp3? Keep the grub2 config with #3? Do we support updates via 'zypper dup'? #20: Michael Chang (michael-chang) (2014-01-23 05:43:57) (reply to #19) The information I got is that while upgrading from sle11-sp3 to sle12, elilo will be replaced by grub2(-efi). That also means elilo config will have to be transformed to grub2's (/etc/default/grub), then let grub2-install and grub2-mkconfig take care the rest. grub2 scripts not deal with the case #3 as it only searches kernel and initrd in /boot. + #21: Steffen Winterfeldt (snwint) (2014-01-23 08:03:19) (reply to #20) + In sle11-sp3 we also used grub2 with an elilo wrapper. So a grub2 + config should already be there, or not? -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Jiri Srain (jsrain) Feature #315499, revision 33 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. #16: Michael Chang (michael-chang) (2013-08-27 13:01:35) (reply to #9) Just finished quick test on 13.1 for grub2 to boot from luks encrypted partition, it works for me with a small glitch that theme file not found (should be rather easy to fix ..). Provide my steps here for reference. cryptsetup luksFormat /dev/vda2 cryptsetup luksOpen /dev/vda2 cr_boot mkfs.ext3 /dev/mapper/cr_boot mount -t ext3 /dev/mapper/cr_boot /mnt cp -a /boot/* /mnt/ umount /mnt mount /dev/mapper/cr_boot /boot GRUB_CRYPTODISK_ENABLE=y grub2-install /dev/vda GRUB_CRYPTODISK_ENABLE=y grub2-mkconfig -o /boot/grub2/grub. cfg And edit /etc/crypttab, /etc/fstab to use new /boot, reboot and grub2 will ask you to provide paraphrase to unlock encrypted /boot and once again in systemd. #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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) Michael, remember that we will need to support SLES11 machines upgraded to SLES12) - and there you cannot create another partition during the update process. #17: Michael Chang (michael-chang) (2013-08-27 13:08:16) (reply to #15) Yes that's very good point .. :) #18: Lukas Ocilka (locilka) (2013-09-05 16:49:18) (reply to #8) Steffen, could you, PLS, evaluate the current development status vs. proposed solution #2 in description? Is that possible? #19: Steffen Winterfeldt (snwint) (2014-01-22 16:47:56) Well, it seems what we have now is #2 (at least on x86) with a /boot/grub2/x86_64-efi subvolume while we will have to deal with #3 in the update case. Michael, is that correct? What is supposed to happen during an update? Keep elilo? And from sle11-sp3? Keep the grub2 config with #3? Do we support updates via 'zypper dup'? #20: Michael Chang (michael-chang) (2014-01-23 05:43:57) (reply to #19) The information I got is that while upgrading from sle11-sp3 to sle12, elilo will be replaced by grub2(-efi). That also means elilo config will have to be transformed to grub2's (/etc/default/grub), then let grub2-install and grub2-mkconfig take care the rest. grub2 scripts not deal with the case #3 as it only searches kernel and initrd in /boot. #21: Steffen Winterfeldt (snwint) (2014-01-23 08:03:19) (reply to #20) In sle11-sp3 we also used grub2 with an elilo wrapper. So a grub2 config should already be there, or not? #22: Michael Chang (michael-chang) (2014-01-23 09:16:41) It is there but not created by grub-mkconfig. Instead it is created and managed by elilo wrapper. I think we have to adapt it to grub-mkconfig process in SLE12. + #23: Jiri Srain (jsrain) (2014-01-23 13:56:55) + Michael, we default to scenario #2. Is there anything missing in GRUB2 + that prevents this feature to be closed as DONE? -- openSUSE Feature: https://features.opensuse.org/315499

Feature changed by: Michael Chang (michael-chang) Feature #315499, revision 35 Title: decide whether ESP (EFI system Partition) is to be used as /boot - openSUSE Distribution: New + openSUSE Distribution: Done 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. #16: Michael Chang (michael-chang) (2013-08-27 13:01:35) (reply to #9) Just finished quick test on 13.1 for grub2 to boot from luks encrypted partition, it works for me with a small glitch that theme file not found (should be rather easy to fix ..). Provide my steps here for reference. cryptsetup luksFormat /dev/vda2 cryptsetup luksOpen /dev/vda2 cr_boot mkfs.ext3 /dev/mapper/cr_boot mount -t ext3 /dev/mapper/cr_boot /mnt cp -a /boot/* /mnt/ umount /mnt mount /dev/mapper/cr_boot /boot GRUB_CRYPTODISK_ENABLE=y grub2-install /dev/vda GRUB_CRYPTODISK_ENABLE=y grub2-mkconfig -o /boot/grub2/grub. cfg And edit /etc/crypttab, /etc/fstab to use new /boot, reboot and grub2 will ask you to provide paraphrase to unlock encrypted /boot and once again in systemd. #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 .. #13: Jiri Srain (jsrain) (2013-08-27 09:50:13) (reply to #12) Yes, #3 IMO better describes what SLES11 and ELILO do. #14: Michael Chang (michael-chang) (2013-08-27 12:43:28) (reply to #13) Oh, my typo, should be "prefer #1 than #3". Yes. that's part of because elilo cannot access files outside ESP so no other choices. And yast2 bootloader is (by design) distinguished bootloader module by each arch and firmware type so that could have created many discrete setups (by different bootloader or firmware "features"). We can avoid many such diversity by a unified loader which can bring us consistent view for different arch and firmware types (although I know/feel many people don't like such "monolithic" beast ..). #15: Jiri Srain (jsrain) (2013-08-27 12:50:27) (reply to #14) Michael, remember that we will need to support SLES11 machines upgraded to SLES12) - and there you cannot create another partition during the update process. #17: Michael Chang (michael-chang) (2013-08-27 13:08:16) (reply to #15) Yes that's very good point .. :) #18: Lukas Ocilka (locilka) (2013-09-05 16:49:18) (reply to #8) Steffen, could you, PLS, evaluate the current development status vs. proposed solution #2 in description? Is that possible? #19: Steffen Winterfeldt (snwint) (2014-01-22 16:47:56) Well, it seems what we have now is #2 (at least on x86) with a /boot/grub2/x86_64-efi subvolume while we will have to deal with #3 in the update case. Michael, is that correct? What is supposed to happen during an update? Keep elilo? And from sle11-sp3? Keep the grub2 config with #3? Do we support updates via 'zypper dup'? #20: Michael Chang (michael-chang) (2014-01-23 05:43:57) (reply to #19) The information I got is that while upgrading from sle11-sp3 to sle12, elilo will be replaced by grub2(-efi). That also means elilo config will have to be transformed to grub2's (/etc/default/grub), then let grub2-install and grub2-mkconfig take care the rest. grub2 scripts not deal with the case #3 as it only searches kernel and initrd in /boot. #21: Steffen Winterfeldt (snwint) (2014-01-23 08:03:19) (reply to #20) In sle11-sp3 we also used grub2 with an elilo wrapper. So a grub2 config should already be there, or not? #22: Michael Chang (michael-chang) (2014-01-23 09:16:41) It is there but not created by grub-mkconfig. Instead it is created and managed by elilo wrapper. I think we have to adapt it to grub-mkconfig process in SLE12. #23: Jiri Srain (jsrain) (2014-01-23 13:56:55) Michael, we default to scenario #2. Is there anything missing in GRUB2 that prevents this feature to be closed as DONE? #24: Michael Chang (michael-chang) (2014-01-24 05:50:00) (reply to #23) We can close this. #2 is the way to go to have unified setup and is main reason to use grub2. -- openSUSE Feature: https://features.opensuse.org/315499