Cure found for kernel updates

[Elad Alfassa]

On Wed, May 14, 2014 at 10:03 PM, Matthew Garrett <mjg59 at srcf.ucam.org>wrote:

> On Wed, May 14, 2014 at 09:57:17PM +0300, Elad Alfassa wrote:
>
> > Only addressing the chainload concern,
> > According to the spec, the bootloader could use both normal configuration
> > AND boot fragments.
> > This means that chainloading can still be done the way it is done now,
> and
> > those boot fragments
> > will only be used to load OSs that implement this specification.
>
> That's doable, but it'd be nice to actually fix it in the spec so we
> don't have to worry about storing configuration in two separate places.
>

Reading the spec, it seems that it's by design that they don't support
chainloading.
It reminds me of the "standard" linux configuration scheme,
where you have something.conf, and then something.conf.d with fragments in
it.

I'm not saying that's a good thing, but I also don't think this should be a
blocker
for us adopting this specification.


> > Regarding the Mac concern, I understand that it's incompatible because we
> > reuse the existing
> > EFI system partition on Mac hardware. Is that correct?
> > Do you have any suggestions on how this can be fixed so we can use the
> > bootloader spec?
>
> Remove the requirement that the ESP be $BOOT. The downside of that is
> that we'll then have *yet another* partition (/boot, because we want
> kernels stored on a filesystem that supports xattrs, /boot/efi for the
> ESP, /boot/whatever for storing the config fragments) which isn't a huge
> issue for GPT but would be annoying with MBR.
>

Can't we store those fragments in the same filesystem /boot is on?


>
> > Having a pile of shell scripts doing such a critical task seems extremely
> > error-prone and broken.
>
> Something's still going to be generating config and something else is
> going to be parsing it, and in this case the breakage could just as
> easily have been caused by whatever writes the fragments.
>
> I'm not denying that, but the notion that those files will be generated
from a template,
instead of copying over the most recent one and then modifying it sounds
more stable
than the current approach too.

I personally think grub2 config files are terrible. You generate it with
one tool on first install,
and then you keep modifying it in place with another tool, keeping the
"don't edit this file" warning on top
which only confuses users more. They are complicated scripts generated by
more complicated scripts,
and the Fedora approach to them is conflicting with the upstream approach,
while neither seems ideal.

The bootloader specification, on the other hand is much simpler for users,
and will result in much simpler
update logic (at least on new installs where we will be able to be sure
people will have bootloaders
which would support this spec. The upgrade path will be a bit more
complicated), and usually simpler
means less points of failure, and less chance of messing things up (in
theory).

Obviously, you are the expert here and I'm probably missing (or being naive
about) a lot of critical problems,
but I do think we should work towards making the bootloader configuration
simpler and less prone to failure.

On that note, is there any way we could verify bootloader configuration
before reboot, so we could
automatically revert to a known-working (ie. the config file we booted
with) configuration in case
the update messed something up?

-- 
-Elad Alfassa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140514/15ec2c56/attachment.html>