Le vendredi 28 juin 2019 à 18:49 -0600, Chris Murphy a écrit : > On Fri, Jun 28, 2019, 1:19 AM Nicolas Mailhot via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le jeudi 27 juin 2019 à 12:26 -0600, Chris Murphy a écrit : > > > 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? > > > > It's not, such magic “it's FCX time” break all the time for users > > that > > only do dnf update, or use rawhide (which branches before the next > > version logic is deployed), etc > > Twice a year for Rawhide. And upon initiation of major upgrade on > release versions. It wouldn't be all the time. > > > > I'm not sure what the alternatives are. > > > > That's, easy, > > > > 1. add a generic bootctl install command that knows the different > > variants of bootloader used in Fedora, how to install them, how to > > identify which variant is appropriate for a system (make grub and > > other > > bootloaders packages install the corresponding info in a directory > > read > > by this command) > > > > 2. make it write the id, generation, and deployment options used in > > a > > lockfile every time it (re)installs the bootloader > > > > 3. add a config file with a variable to inhibit auto-redeployment > > > > 4. add a scriptlet to the bootctl package that calls bootctl > > install > > and > > – checks the variant in the lockfile is appropriate for the > > hardware > > (in case of disk mode or copy) > > – checks if the generation is current or unknown (unknown = > > future, do > > not touch) > > – and if any of those is false, reinstalls the bootloader, unless > > the > > inhibit variable is set > > > > 5. add a --force switch to bootctl to allow the operator to force a > > bootloader rewrite every time somethins else broke it > > I think that's completely out of scope. It's inappropriate to wait 10 > months let alone 10 years to resolve this problem. And it's an overly > complicated solution. It's not an overcomplicated solution it's just putting a single stable unchanging installation command in front of whatever anaconda does. Which grubby was not since it was grub-specific with lots of options. Not making the effort to put this single command in place, is the reason why Fedora boot problems in 2019, are the same than RHL boot problems in 2000: 1. no one knows exactly what to call to reinstall the bootloader except bootloader people (it changes and is badly documented), 2. therefore no one can test the result on the scale needed for the variety of hardware out there 3. when someone hits a bootloader problem, and tries to fix his system with whatever lies on the internet (because the documentation is not here, and the documentation is needed, because the actual commands to type change), it's never exactly what bootloader people think he should do, so the result is invalid (positive or negative), and not used to improve the way Fedora does things 4. because there is no master command, and the actual commands change over time, there is no incentive to do something in new sets of commands, that salvages whatever was done in the previous set of commands 5. it ends up in new full system installs just to get anaconda to the point it does this part (and RHL supported in-place updates, while Fedora will insist on blowing up the previous install) 6. and everyone involved insists it's "too complex" to set up an easy to document master install command 7. something should be put in place "now" and not wait 10 months or 10 years Well Fedora and RHL have spent 20 years avoiding cleaning up this mess and it's still the same original mess so at one point 10 months seems awfully short period to get it done. Regards, -- Nicolas Mailhot _______________________________________________ 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
