On Sat, May 04, 2019 at 01:35:32PM -0600, Chris Murphy wrote: > On Sat, May 4, 2019 at 12:31 PM Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote: > > > > Chris Murphy writes: > > > > > Actually, that's a problem too. The stale bootloader problem goes back > > > to an era where it was possible to install the bootloader into the > > > first sector of the boot partition, and in those cases, /dev/sda1 is > > > actually valid. And again, no practical way to discover this > > > automatically in advance. > > > > It would be useful to have dnf system-upgrade emit a "say, you may need to > > X first" message, before initiating a reboot, with an opportunity to bail > > out. Just like the existing message that tells you to update the current > > system first, before initiating an upgrade. > > The reminder to update the current system applies to everyone. Whereas > the mitigation for this bug is for specific configurations that the > plug-in can't test for, and for other configurations it's not good > advice. Suggesting UEFI users run 'grub2-install' will have two > possible outcomes: non-standard GRUB behavior if the command works; > and confusion if 'grub2-install' doesn't work because it isn't > present. Either way, it's bad advice because that's a bad UX. > > While handling this bug with a Common Bugs report is suboptimal, it > has long been expected that users should read Common Bugs before > installing or upgrading their systems. Making that advice more > prominent might be reasonable. > > > And, making this more generic, each new Fedora release could have a brief > > upgrade message tucked away in it, somewhere, that dnf system-upgrade could > > grab and show up front. > > As simple as it sounds, someone has to build that and maintain it, > from upstream down to Fedora. And Fedora also supports two upgrade > mechanisms, dnf system-upgrade, and GNOME Software. And I think it's > reasonable that such messages to user space need to follow > localization guidelines, so now those messages need translation. > That's a lot of work to do when, again, we're all supposed to read > Common Bugs. It's not any different on Windows or macOS who publish > release notes, if you're very lucky they report some gotchas, but they > never do that notification in the actual upgrade tool. There was the pre-upgrade tool (https://fedoraproject.org/wiki/How_to_use_PreUpgrade), but I don't think it ever went anywhere. IMHO, we just don't have the manpower to maintain such a tool in the face of the frequent releases and the myriad of possible installation styles and combinations of upgrade paths. For something more stable and limited and predictable like RHEL this might be possible, but I don't see it ever happening for Fedora. > The reason why this bug exists in my opinion is because we're being > too accommodating to the technical users who want linux multiboot, and > want Fedora to not step on their bootloader. I'm not convinced that's > a very good policy anymore. I personally would flip it around and > forcibly update the bootloader by assuming we own it, and if it turns > out that's the wrong assumption the injured party is a technical user > who should be familiar with linux mulit-boot madness and its esoteric > work arounds. This makes the assumption, which was also made earlier in the thread, that it's somehow impossible to check what bootloader is installed. Why? My bootloader is happy to tell me its version: $ bootctl ... Current Boot Loader: Product: systemd-boot 241-565-g43d51bb Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control File: /EFI/systemd/systemd-bootx64.efi ... Nowadays it's gives the exact git commit it's built from, in the past it was just the release version, but either is enough. Therefore 'bootctl update' can fairly reliably *update*, i.e. do the installation if the thing we have is newer than the version already installed. In case of grub and MBR things are a bit more involved, but I don't think there's any significant technical limitation to doing the same check and conditional installation. Zbyszek _______________________________________________ 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
