Re: always update the bootloader during major upgrades
Hello Chris, Thanks for bringing this topic and sorry for the late reply. On Wed, Jun 26, 2019 at 10:20 PM Chris Murphy wrote: > > Hi, > > This is not a formal proposal, this is for discussion and identifying > liabilities. This email has an x86 GRUB bias only because that's the > bootloader regime I'm most familiar with. I think it should apply to > other archs as well, i.e. their bootloaders shouldn't be permitted to > become stale. > I agree with you on this. I've commented my thoughts in the fedora-workstation issue you created: https://pagure.io/fedora-workstation/issue/97#comment-580794 Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
On Sat, Jun 29, 2019 at 5:24 AM Richard Shaw wrote: > > I don't have the technical expertise in this area to comment on the details > of the implementation, but from a dumb user point of view, could there be a > simple or no-payload package that says "Fedora owns the bootloader" that's > installed by default and power users that wish to maintain it themselves (or > use other bootloaders) and remove the package? I like this idea. Would bootloader projects be willing to use a single canonical location and format for this indication? On the other hand, if I don't want to use the Fedora GRUB bootloader, why do I have that package still installed? If I were using the Ubuntu bootloader, or systemd-boot, I would uninstall all the GRUB stuff to ensure it's not being used, accidentally or otherwise. Nevertheless, I'm OK with the idea that BIOS GRUB not be automatically reinstalled everytime there's a package update, but rather postpone it for major Fedora upgrades. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
On Sat, Jun 29, 2019 at 1:05 AM Nicolas Mailhot via devel wrote: > > Le vendredi 28 juin 2019 à 18:49 -0600, Chris Murphy a écrit : > > 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. grubby isn't GRUB specific. It supports LILO, ELILO, SILO, ZIPL, extlinux, GRUB legacy, GRUB2, yaboot, and something else I'm forgetting no doubt. This also seems applicable https://xkcd.com/927/ > 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: a. Near as I can tell, the only system under discussion, x86 + BIOS + multiboot, means exactly one bootloader: BIOS GRUB. That's the only bootloader Fedora supports in that configuration. b. Fedora only narrowly supports multiboot: Fedora + Windows, and Fedora + macOS. As in, only the dual boot variety, and not any Linux distros. Not even Fedora + Fedora is supported. By that I mean, there is no release criteria that forms a basis for blocking the release if something related to creating such a setup during installation is found to be broken. I just don't see how a single command to rule them all solves a single problem. It's like playing musical chairs, except no seat has been removed. > 1. no one knows exactly what to call to reinstall the bootloader except > bootloader people (it changes and is badly documented), Fedora x86 BIOS, it's been 'grub2-install' since circa Fedora 14. And on UEFI since early days it's reinstall shim and grub packages, also hasn't changed. > > 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 But in effect you're proposing the inevitable day when the user still invokes grub2-install, and the Fedora oracles still say "yeah that's deprecated on Fedora, you ran the wrong command, that's why your system is now hosed" By the way, bootctl is already taken by systemd-boot. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
I don't have the technical expertise in this area to comment on the details of the implementation, but from a dumb user point of view, could there be a simple or no-payload package that says "Fedora owns the bootloader" that's installed by default and power users that wish to maintain it themselves (or use other bootloaders) and remove the package? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
Le vendredi 28 juin 2019 à 18:49 -0600, Chris Murphy a écrit : > On Fri, Jun 28, 2019, 1:19 AM Nicolas Mailhot via devel > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
Le vendredi 28 juin 2019 à 09:06 -0700, Adam Williamson a écrit : > On Fri, 2019-06-28 at 09:18 +0200, Nicolas Mailhot via devel wrote: > > 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) > > I am not sure you quite understand the meaning of the word "easy". :P It's the same core logic that already exists in anaconda, and in the envisionned dist upgrade, except packaged in a sane reusable easy to test unit. Packaging it sanely does not make the core logic simpler sure, but it removes the mass of problems caused by bootloader installations happening in multiple badly defined in-between gray dimensions, without any tracking of what was effectively done in the past. And the core logic need to be maintained in any case. So yes, I do believe that quick and dirty is more difficult in the long run. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
On Fri, 2019-06-28 at 09:18 +0200, Nicolas Mailhot via devel wrote: > 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) I am not sure you quite understand the meaning of the word "easy". :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
Le jeudi 27 juin 2019 à 12:26 -0600, Chris Murphy a écrit : > On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III > wrote: > > On Wed, Jun 26, 2019 at 14:19:26 -0600, > > Chris Murphy 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? 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 > 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 -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III wrote: > > On Wed, Jun 26, 2019 at 14:19:26 -0600, > Chris Murphy 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
On Wed, Jun 26, 2019 at 14:19:26 -0600, Chris Murphy 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
