[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]


This is a followup to:

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

Now fast forward a bit, and mainly Chris convinced me in:
that the BLS design of having kernels/initramfs on FAT isn't right.  See

There's another thread here, which is that I recently discovered grub2
has support for reading syslinux config files:

This dovetails with a Fedora feature Dennis created to use syslinux
config files for u-boot:
(Incidentally OSTree has code to generate u-boot too:
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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]