Hello Chris,
Thanks a lot for the comments.
On Thu, Dec 31, 2020 at 1:02 AM Chris Murphy <lists(a)colorremedies.com> wrote:
[snip]
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.
Correct.
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 agree with you but users have different expectations I think. If
they deviated from the default and that didn't cause issues for them
after a system wide upgrade, they expect that to be the case on the
next update.
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.
Yes, for me is less about this tiny window but more about users having
modifications in their GRUB config file that will be overwritten when
generating a new one. For example in the BLS conversation some users
update their kernel cmdline in the grub.cfg and that didn't match the
GRUB_CMDLINE_LINUX in /etc/default/grub. Maybe what we can do is to
not generate a new /boot/grub2/grub.cfg but instead copy the one in
the ESP to cover these corner cases ?
I'll update the proposal based on the feedback.
Best regards,
Javier