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. Best regards, Javier _______________________________________________ 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/EZKEX565RVCWKIBJLWSKZWR7HJUWBZNO/
