On Mon, Jun 18, 2018 at 11:02 AM, Javier Martinez Canillas <javier@xxxxxxxxxxxx> wrote: > On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson >> <adamwill@xxxxxxxxxxxxxxxxx> wrote: >>> On Thu, 2018-06-14 at 12:06 +0200, Jan Kurik wrote: >>>> == Scope == >>>> * Proposal owners: >>>> ** Generate BLS snippets at kernel build time and ship in the kernel packages. >>>> ** Make kernel-install scripts to copy the BLS, kernel and initramfs >>>> images and do any architecture specific task. >>>> ** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot >>>> menu entries from the information in BLS files. >>>> ** Have a grubby wrapper for backward compatbility that manipulates BLS files. >>>> ** Modify packages that use grubby to instead install BLS fragments >>>> (memtest86+, tuned). >>>> ** Make sure this is all properly documented in release-notes, etc. >>> >>> What exactly is the plan for upgrades, here? >> >> >> "users upgrading from a previous version of Fedora will keep the old >> behaviour. " >> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.2Fcompatibility_impact >> >> I'm on the fence whether I think it's better to support two bootloader >> configurations, or compel upgrades to use the new method at some point >> and when, rather than having a community with multiple personalities >> confusion. >> >> The cited BLS spec is the original one, not the more thoroughly >> discussed and thought through variant by Matthew Garrett [1] some >> years ago. >> >> What are we getting from the cited spec? All of it? Are there >> exceptions? Where are the exceptions written? >> > > The BootLoaderSpec document was cited mostly for context in case > someone was not familiar with the BLS concept. We support multiple > architectures in Fedora and not all of them use UEFI (e.g: ppc64le and > s390x), so we used the spec as a reference rather than following it > verbatim. > > The value I think is in having the same file format for all supported > architectures by Fedora, so we can make tools able to parse and manage > them without needing to care about different file formats per > bootloader. It's true that we don't need BLS for that, since we could > do the same than other distros and use the grub config file for > everything (for example SuSE chain-loads zipl with grub-emu on s390x > so they can use a grub.cfg instead of a zipl.conf there). But the > advantage of BLS is that allows to have system configuration changes > as atomic operations that don't require parsing a monolithic config > file. > >> The cited BLS spec requires $BOOT be VFAT, are we doing that? >> > > Yes for EFI systems but no otherwise. On EFI the BLS snippets are in > /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in > /boot/loader/entries. > >> The cited BLS spec requires kernels and initramfs go on $BOOT, are we >> doing that? >> > > No, the kernel and initramfs images are in /boot. By default in Fedora > we keep 3 kernel + initramfs images (installonly_limit=3 in > /etc/dnf/dnf.conf) + the rescue images (only the rescue initramfs is > ~500MB). So as you said it's not realistic to have all the images in > the ESP. > >> Are we going to stop doing the diabolical (and widespread) nested >> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent >> mounting of these volumes in favor of mounting/unmounting dynamically >> only by the programs that are authorized to make changes to these >> volumes? >> > > That remains the same for now, the proposed change is only about > populating the boot menu entries from BLS files instead of the > bootloader configuration file. > >> If there's no room on the EFI System partition for all of this, will >> we following bullets 2 and 5 of the BLS spec under "The installer > > No, $BOOT is always the ESP where GRUB 2 is installed. Thanks for the reply. I think the proposal title is misleading. The BLS file format is, depending on one's point of view, 5% of the spec. A bulk of the proposal isn't going to follow the spec at all. And even with regards to the file format, you're not following the spec which mandates all paths relative to $BOOT, which clearly isn't going to be the case. And that makes the BLS file format you're implementing, more close to GRUB legacy, and the Matthew Garrett BLS format derivative, than the original BLS spec format. I think the feature proposal should be rename: 'Make using BootLoaderSpec style file format the default' The proposal doesn't follow the BLS spec in some of the most critical ways necessary to get it adopted by upstreams and other distros. My summary of the change for most users (x86_64) - /etc/grub.d/10_linux will no longer contain Fedora entries, each menu entry will be a BLS format drop in script instead - grub.cfg still is responsible for multibooting Windows and other distros via /etc/grub.d/30_os-prober - users will no longer modify /etc/default/grub, they will duplicate (?) and modify BLS scripts directly if they need to make permanent changes to menu entries - users will no longer need to run grub2-mkconfig, unless the grub.cfg is accidentally missing or malformed - users on BIOS systems who install another distro after Fedora, will need to inform the distro's installer to not overwrite the Fedora bootloader, or the user will need to reinstall the Fedora bootloader; until such time as distro bootloaders support the BLS format -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/LDO2MBATEX63HWEX4JIPUU54T3IS7H6K/
