Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

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

 



On Wed, Dec 30, 2020 at 5:01 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Dec 30, 2020 at 2:09 PM Javier Martinez Canillas
> <javier@xxxxxxxxxxxx> wrote:
>
> > On Wed, Dec 30, 2020 at 9:22 PM Adam Williamson
> > <adamwill@xxxxxxxxxxxxxxxxx> wrote:
>
> > > * We wouldn't have a "consistent configuration" across everybody,
> > > really, because anyone who upgraded from pre-F34 would still have the
> > > old config; every bootloader debugging session ever would start by
> > > figuring out which case this was.
>
> > These are all fair points. My worry is that trying to switch to the
> > new configuration on upgrades could lead to issues for people that
> > have custom GRUB configs. That was the case when we did the switch to
> > using BLS snippets and I don't really want to repeat that experience
> > for users.
>
> That problem was the result of quite old core.img in the MBR gap (or
> BIOS Boot partition). As that change simultaneously depended on
> shipping a new GRUB module without a way to update the core.img with
> up-to-date GRUB modules, there was a known weak spot that we even knew
> of in advance.
>
> Upgrades of customized configurations that deviate significantly from
> defaults aren't supported. It's best effort. We can't be blocking on
> people's customizations.
>
> I think we can come pretty close to atomically renaming
>
> /EFI/fedora/grub.cfg /EFI/fedora/grub.cfg.old
> /EFI/fedora/grub.cfg.new to /EFI/fedora/grub.cfg
>
> And at least ensure the user can boot the old one, but even this I
> think is pretty unlikely. It's really a teeny tiny window of failure
> opportunity. And based on my reading of rename() if the files are
> already all present, and all we're doing is renaming them, there
> shouldn't be a case where grub.cfg is either missing entirely or zero
> bytes.
>
> But dm-log-writes can help confirm or deny this. What I don't know is
> if this can be done with bash. The convert script probably needs to be
> done in C. Or at least the rename and sync parts.


Oh I forgot the part about the convert script testing for custom
grub.cfg. Maybe it's possible to parse it first, and if it's custom,
bail. If it's non-custom then convert it.

And a variation where we have an opt-in for this convert script for
Fedora 34 cycle. And then ship it and do the conversion in Fedora 35.

I think either never fixing this, or never updating systems to the
"new way" are both untenable. We saw with the BLS switch many users
depend on doing in place upgrades. Many were pushing 4 or more years.

-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux