This is a followup to: https://bugzilla.redhat.com/show_bug.cgi?id=1101359 https://bugzilla.redhat.com/show_bug.cgi?id=1100938 While it's not strictly related to Anaconda the codebase, this is a good mailing list which has the relevant participants, and I find email to be better for architectural discussions than Bugzilla. Now, unfortunately the OSTree model definitely impacts the bootloader situation badly. The fundamental promise of it is that upgrades are atomic, and the way that's implemented is for it to be in control of the bootloader configuration, specifically to perform an atomic replacement. That bootloader configuration then has an ostree= kernel argument which is used in the initramfs. The original design was to use the http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ - it had the promise of bootloader-independent configuration. I really liked that idea, as it got me out of the grubby-like model of having to keep up with lots of file formats for the many bootloaders. Peter did add support for the BLS to grub2. However at the time, syslinux didn't implement BLS, and rather than hack it, I cowardly decided to take the easy route and just generate syslinux configs as well. Now fast forward a bit, and mainly Chris convinced me in: https://bugzilla.redhat.com/show_bug.cgi?id=1101359 that the BLS design of having kernels/initramfs on FAT isn't right. See also: https://lists.fedoraproject.org/pipermail/desktop/2014-June/009962.html There's another thread here, which is that I recently discovered grub2 has support for reading syslinux config files: http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/commands/syslinuxcfg.c This dovetails with a Fedora feature Dennis created to use syslinux config files for u-boot: http://fedoraproject.org/wiki/Changes/u-boot_syslinux (Incidentally OSTree has code to generate u-boot too: https://git.gnome.org/browse/ostree/tree/src/libostree/ostree-bootloader-uboot.c that could go away) Now, this offers the opportunity to basically have the unified configuration aspect of the BLS, without anything else. We retain the current way UEFI boots work. OSTree and grubby remain the tools to read/write bootloader configuration (we could entertain some code merging but I don't see that as a priority). One thing to work out with this I think would be how probed entries were merged with static syslinux config entries. Or would we just do probing at install time? Does that all make sense? _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
