Supporting Grub2-BLS #708
Supporting Grub2-BLS #708
Conversation
|
I add some comments that needs to be clarified...but more importantly to make it work I worry it needs also changes in yast2-storage-ng as currently EFI partition is 256MiB which is quite small for BLS which in the latest specification mention EFI of 1GiB to be able to have inside enough kernels. |
This 1GiB is for UKIs, and we are not using it now. For the current systemd-boot (already merged) and this grub2-bls, 512MiB should be OK (is what MicroOS is using). The kernel and the initrds are reused, so we can have multiple active snapshots represented in the ESP. But this decision should be done by the bootloader team, in case that they have a different vision here. About the mechanism ... is this bls=1 set by the user? That is dangerous IMHO, as I select the bootloader much later |
As said, now it is 256MiB with 128MiB minimum, which is too low from my understanding of BLS. So it will need to adapt to whatever value and as mentioned even with that 256MiB users complain that it is too much space. mechanism is like with fips. It is set on kernel cmdline during boot of medium and then it changes what installer propose. In agama it will be more straightforward as it do not use wizard approach, but yast installer use wizard and storage is done very soon and bootloader later. So idea is that user set bls=1 on kernel cmdline and it will propose big enough EFI partition to fit BLS based bootloader and then user can change it to even common one, but EFI proposed size will remain. |
That is the part that does not make sense to me. The selection of the bootloader comes later. I select grub2-bls or systemd-boot in YaST with some graphical interface, and I would expect that the proposal changes to the expected sizes and layout that make sense from my selection. Maybe something that makes a bit more sense, from the user PoV, is that if the system has EFI then the selected layout would be such that mount the ESP in /boot/efi with "enough" size, whatever means means for this version of the installer. I do not know if the XML that defines the disk layout and some of the defaults (the skel file) can condition the size of the ESP under the condition of the selected boot loader, but this can be another path that can work. |
That's a historical problem we have with YaST that makes hard to fit this case. YaST is a wizard and the storage (partitioning) setup is one of the first steps that is configured by the user. But tuning the configuration of the boot loader is something that gets done almost at the end of the process, right before starting the installation. The partitioning setup has already been reviewed, adapted and accepted by the user, we cannot simply change it (for a variety of reasons).
That means we grow the EFI for everyone. Both people using the default boot loader and those using Grub2-BLS. I can tell you there will be a lot of people unhappy with that. For whatever reason, people tend to be very sensitive about having too big UEFI partitions (for their own individual definitions of "too big").
The size of those boot-related partitions are calculated based on different so-called "strategies". We have the following strategies: Legacy (for BIOS-based systems), NFSRoot (for systems without local storage), PReP (for powerPC systems), Raspi (for Raspberry Pi), UEFI (for standard EFI-based systems) and Zipl (for s390). We add new strategies as we need to cover more scenarios. We could perfectly develop a separate strategy for Grub2-BLS+EFI. But the original problem remains - the installer needs to choose a strategy and stick to it. And the selection happens during the step that sets the initial storage configuration. So we use criteria like the architecture, the product, the location of "/" and any other aspect that is known at that point. If we are going to use the chosen boot-loader as a criteria to choose the strategy, then such a decision needs to be known during the partitioning step. |
Can next idea fit in YaST?
Ideally we can move architecture by architecture to the new layout once they are better tested and enabled. |
For the first step I would prefer this solution. While implementation and testing I have not had any issue regarding disk space. So I am wondering why we are insisting on the 1GByte size so strictly. |
The current model (shared kernel and initrd between snapshots, as sdbootutil uses) do not requires 1Gb of EFI space, but if the idea is moving in the future to UKIs, then this size seems more reasonable. UKIs can be shared now, as certain components can live outside them with new systemd versions (like the cmdline), but I suspect that the re-usage index will be lower than the current approach. |
As written above, my Tumbleweed reference machine, auto-updating daily since month, uses 480MB of |
|
Also 1GiB is specified in BLS itself even thought quite vague as |
It's surely doable and sounds like a sensible approach to move forward.
For the yast2-storage-ng part, that's just a matter of adding the related logic to https://github.com/yast/yast-storage-ng/blob/master/src/lib/y2storage/boot_requirements_checker.rb#L125 For the yast2-bootloader part I guess it's also possible to define the default bootloader using any reasonable criteria (I'm not that familiar with that part of the code).
That should be doable as well. We would need to decide which mechanism to use for that check, but it doesn't sound hard to implement. |
|
For bootloader changing default bootloader is mainly about changing logic at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/bootloader_factory.rb#L116 which is the part of code that is responsible for it. |
One important note. That logic to decide whether to go for grub2-bls should be configurable by "product". I'm pretty sure we don't want to change yet the behavior for SLES-16 or other enterprise products, neither for Agama-based installations (until we have tried it in YaST), etc. So, at least for the time being, we should likely introduce a new configuration option. That would allow us to specify if we want to "try" (if all the other conditions are met) grub2-bls for a given product (only TW installed with YaST, in this case) or even per system role. |
Yes, we want to change the behavior for SLES-16 now: https://jira.suse.com/browse/PED-10703 |
So if I get that jira entry properly it is requested to have big enough EFI partition for x86_64 and aarch64 and to also have 1GiB /boot/zipl on s390 to allow future transition. And also no change on ppc. Do I get it correctly? |
Ignore s390x for now. That's still not clearified and in evaluation.
PM does not want a difference in SL Micro 6.x and SLES16, both should use the same bootloader setup. |
|
I will try to go Ancors way, defined in:
As Josef has already mentioned, the question could be answered around here: https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/bootloader_factory.rb#L116 |
| if current_bl.respond_to?(:pmbr_action) | ||
| current_bl.pmbr_action = value | ||
| else | ||
| log.error("Bootloader #{current_bl} does not support PMBR.") |
There was a problem hiding this comment.
JFYI PMBR is not about bootloader support as it is set by parted. For more info https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#protective-mbr Basically it is for backward compatibily for stuff that do not understand GPT and needs MS DOS table. But it has some disadvantages, so for EFI boot we usually unset it.
| @@ -62,6 +91,9 @@ def trusted_boot_active? | |||
|
|
|||
| # Check if the system is expected to have nvram - ie. update_nvram_active? makes a difference | |||
| def nvram_available?(bootloader_name = nil) | |||
| # not for grub2-bls | |||
| return false if bootloader_name == "grub2-bls" | |||
There was a problem hiding this comment.
@aplanas Just to be sure, grub2-bls cannot skip writing to nvram? I remember that especially some aarch64 devices has problems to write to it and needs this "workaround" which skips write to it, otherwise a crash happen. I can find some bugzilla references, if you are interested.
| # param bootloader_name [String] bootloader name | ||
| # @return [Boolean] true if supported | ||
| def console_supported?(bootloader_name) | ||
| !Yast::Arch.s390 && bootloader_name != "grub2-bls" |
There was a problem hiding this comment.
@aplanas Just to be sure grub2-bls does not support neither graphical console neither serial console? Especially later one can be a bit problematic on servers. Or it works in different way and is just not configurable and detect serial console automatic?
| # param bootloader_name [String] bootloader name | ||
| # @return [Boolean] true if supported | ||
| def password_supported?(bootloader_name) | ||
| bootloader_name != "grub2-bls" |
There was a problem hiding this comment.
@aplanas just to be sure password protected grub is not supported at all with grub2-bls? I remember that some customer even requires old grub1 way of password protection (so with grub2-efi we support both password protection again boot entry modification and also whole boot password protection), so they can see it as regression.
There was a problem hiding this comment.
grub2-bls can be extended via grubenv block, but I do not see there a way to set passwords, so I would say that grub2-bls cannot be protected with passwords today. But mchang will give the last word here.
IIUC the password protected grub2 is about avoiding users to edit the menu entry and such. This is already covered by the TPM2 and measured boot.
I have made a PR: |
What is missing from my side? |
|
@aplanas answer to this question about grub2-bls support for consoles #708 (comment) |
Added grub2-bls support which has been announced:
https://news.opensuse.org/2024/10/08/grub2-bls
jsc#PED-10703
Testing
Added new unit tests
Tested manually
-- New installation
-- In installed system
-- AutoYaST installation
Screenshots