From: Steven Haigh <netwiz@crc.id.au> To: George Dunlap <dunlapg@umich.edu> Cc: xen-devel <xen-devel@lists.xenproject.org> Subject: Re: pygrub not starting first menuentry in Fedora 30 Date: Tue, 14 May 2019 23:49:46 +1000 [thread overview] Message-ID: <1557841786.2639.0@crc.id.au> (raw) In-Reply-To: <CAFLBxZawmyFKLko0PhhfJHuVBdqzhkYzyQZAeo2Z9eTX=YkEPA@mail.gmail.com> On Tue, May 14, 2019 at 11:40 PM, George Dunlap <dunlapg@umich.edu> wrote: > On Mon, May 13, 2019 at 11:25 AM Steven Haigh <netwiz@crc.id.au> > wrote: >> >> There seems to be some changes in Fedora 30 that cause the second >> boot >> entry in grub.cfg to be booted instead of the first. >> >> This means that Fedora 30 systems either always boot into an older >> kernel, or in the case of systems with only one kernel installed, >> the >> rescue image. >> >> There also seems to be some new issues with the move to BLSCFG - >> however it seems a new requirement is to have >> GRUB_ENABLE_BLSCFG="false" in /etc/default/grub. This causes >> grub2-mkconfig to work correctly and spit out a grub.cfg file that >> pygrub can then use. >> >> Is this a bug in pygrub, or a problem with how Fedora 30 generates a >> grub.cfg? >> >> I tried to pick through pygrub - but couldn't quite follow the >> python >> logic to see where the default boot option is selected. > > AFAICT, the basic issue is that pygrub is a partial re-implementation > of grub, and hasn't re-implemented the blscfg functionality. I don't think this is an issue. When using 'GRUB_ENABLE_BLSCFG=false' in /etc/default/grub, the grub config file is generated correctly and works as expected. The problem is not that it doesn't work, but something is causing an offset in the default menu item (almost like an off-by-one) that causes the *second* entry in the grub.cfg to boot. > The *most robust* solution going forward is always going to be to use > grub-xen (AKA pvgrub2) instead of pygrub. grub-xen is a port of the > actual grub project to run as a PV guest, and so will always be the > most compatible with upstream grub. > > Not sure who's "in charge" of pygrub enough to teach it how to use > blscfg. I'm not sure there's a huge rush for this... If upstream grub installers checked to see if it was installing on a Xen DomU, then set GRUB_ENABLE_BLSCFG=false by default - the remaining fix should be rather simple to figure out - after all, functionality is correct - apart from the wrong entry being selected by default. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
WARNING: multiple messages have this Message-ID (diff)
From: Steven Haigh <netwiz@crc.id.au> To: George Dunlap <dunlapg@umich.edu> Cc: xen-devel <xen-devel@lists.xenproject.org> Subject: Re: [Xen-devel] pygrub not starting first menuentry in Fedora 30 Date: Tue, 14 May 2019 23:49:46 +1000 [thread overview] Message-ID: <1557841786.2639.0@crc.id.au> (raw) Message-ID: <20190514134946.LZQ6oNUwwaO1c2g5KtaoXnvrROPX3SnvzTerwW6cvQw@z> (raw) In-Reply-To: <CAFLBxZawmyFKLko0PhhfJHuVBdqzhkYzyQZAeo2Z9eTX=YkEPA@mail.gmail.com> On Tue, May 14, 2019 at 11:40 PM, George Dunlap <dunlapg@umich.edu> wrote: > On Mon, May 13, 2019 at 11:25 AM Steven Haigh <netwiz@crc.id.au> > wrote: >> >> There seems to be some changes in Fedora 30 that cause the second >> boot >> entry in grub.cfg to be booted instead of the first. >> >> This means that Fedora 30 systems either always boot into an older >> kernel, or in the case of systems with only one kernel installed, >> the >> rescue image. >> >> There also seems to be some new issues with the move to BLSCFG - >> however it seems a new requirement is to have >> GRUB_ENABLE_BLSCFG="false" in /etc/default/grub. This causes >> grub2-mkconfig to work correctly and spit out a grub.cfg file that >> pygrub can then use. >> >> Is this a bug in pygrub, or a problem with how Fedora 30 generates a >> grub.cfg? >> >> I tried to pick through pygrub - but couldn't quite follow the >> python >> logic to see where the default boot option is selected. > > AFAICT, the basic issue is that pygrub is a partial re-implementation > of grub, and hasn't re-implemented the blscfg functionality. I don't think this is an issue. When using 'GRUB_ENABLE_BLSCFG=false' in /etc/default/grub, the grub config file is generated correctly and works as expected. The problem is not that it doesn't work, but something is causing an offset in the default menu item (almost like an off-by-one) that causes the *second* entry in the grub.cfg to boot. > The *most robust* solution going forward is always going to be to use > grub-xen (AKA pvgrub2) instead of pygrub. grub-xen is a port of the > actual grub project to run as a PV guest, and so will always be the > most compatible with upstream grub. > > Not sure who's "in charge" of pygrub enough to teach it how to use > blscfg. I'm not sure there's a huge rush for this... If upstream grub installers checked to see if it was installing on a Xen DomU, then set GRUB_ENABLE_BLSCFG=false by default - the remaining fix should be rather simple to figure out - after all, functionality is correct - apart from the wrong entry being selected by default. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-14 13:49 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-13 10:24 pygrub not starting first menuentry in Fedora 30 Steven Haigh 2019-05-13 10:24 ` [Xen-devel] " Steven Haigh 2019-05-14 13:40 ` George Dunlap 2019-05-14 13:40 ` [Xen-devel] " George Dunlap 2019-05-14 13:49 ` Steven Haigh [this message] 2019-05-14 13:49 ` Steven Haigh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1557841786.2639.0@crc.id.au \ --to=netwiz@crc.id.au \ --cc=dunlapg@umich.edu \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).