On Wed, May 14, 2014 at 10:03 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
I personally think grub2 config files are terrible. You generate it with one tool on first install,
On Wed, May 14, 2014 at 09:57:17PM +0300, Elad Alfassa wrote:That's doable, but it'd be nice to actually fix it in the spec so we
> 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.
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.
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.
for us adopting this specification.
Remove the requirement that the ESP be $BOOT. The downside of that is
> 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?
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?
Something's still going to be generating config and something else is
> Having a pile of shell scripts doing such a critical task seems extremely
> error-prone and broken.
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.
instead of copying over the most recent one and then modifying it sounds more stable
than the current approach too.
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,
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
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.
-- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
