On Sat, May 4, 2019 at 12:44 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > On Saturday, May 4, 2019 1:43:56 PM EDT Chris Murphy wrote: > > Currently, there is no way to determine who owns the bootloader on a > > BIOS computer, and therefore to avoid stepping on a bootloader that we > > don't own, we never update it. > > I would imagine it is trivial to examine the files to see that there is only > one system installed and handle that case. Multi-boot is more complicated. It's trivial if you're willing to make assumptions rather than test for conditions. If you start testing for conditions you quickly find a ton of exceptions. I can easily create a multiboot system that partitioning wise looks like a default/automatic Fedora only system. So you need a test that doesn't only check number and type of partitions. It'd have to be deeper than that. If you open it up to custom configurations then it's even more tests you have to do to know for sure it's a single OS system. I think that's super complicated and not at all trivial, it'll hit all kinds of edge cases. This bug itself was expected to be an edge case, that not many users would be affected, in that not many would have a stale Fedora 20 or older bootloader. Surely 'grub2-install' would have been manually run, or the user has done a recent clean install since Fedora 20, right?! Possibly the assumption about upgrades is wrong because they have been so reliable that users trust them. In other words, the problem is the result of our own success! And if that's true, revisiting the 'don't update the bootloader on BIOS' policy perhaps is in order. There are in fact real security bugs that crop in the bootloader from time to time, and no one on BIOS gets the benefit of fixes for those vulnerabilities if they do not run grub2-install manually. It's insufficient to just update the RPMs on BIOS systems. Anyway, I for one would strongly support changing this with the feature process. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
