On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III <bruno@xxxxxxxx> wrote: > > On Wed, Jun 26, 2019 at 14:19:26 -0600, > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > >Short version: Fedora should take responsibility for the bootloader > >being up to date, by updating it during major version upgrades. This > >is already the case on UEFI with conventional installations. I'd like > >to make sure it always happens on major version upgrades for BIOS > >installations. What's the problem? This would step on any custom > >bootloader configuration a user has for multiboot. There is no > >reasonable mechanism on BIOS systems to determine if the bootloader is > >a Fedora bootloader, and somehow only update a Fedora bootloader and > >not touch any other bootloader. > > How do you envision this working for rawhide? > I had a problem where grub1 configs were no longer updated with kernel > updates, where I finally needed to upgrade to grub2. Yep, small problem. And I'm not even sure how a 'grub2-install' on BIOS systems would be initiated only at major upgrade time. But even Fedora Rawhide does change versions when fcXX becomes fcXX+1, but is that a sane trigger? I'm not sure what the alternatives are. And could there be a policy setting in /etc/default/grub for this, where the user can opt out? And should such an opt out exist? There is no such opt out for UEFI. Anyway, the how to do this is a different question than whether to do it, and whether the policy is the same across all Fedora editions, spins, images, etc. I think it's uncontroversial to say on IoT the bootloader must be updated, I imagine no reasonable justification for making this user domain on this class of device. That is probably also true for cloud/virtual, and baremetal servers. It's really desktops that there's an open question of what/who owns the bootloader. And there I'd say the default really ought to be, maybe even must be, update the bootloader with some regularity. And if that's true and agreed upon, then fill in the gaps with some needed details: how often, how to do it, should there be an opt out, and how to implement that, etc. -- 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
