* pygrub not starting first menuentry in Fedora 30
@ 2019-05-13 10:24 Steven Haigh
2019-05-13 10:24 ` [Xen-devel] " Steven Haigh
2019-05-14 13:40 ` George Dunlap
0 siblings, 2 replies; 6+ messages in thread
From: Steven Haigh @ 2019-05-13 10:24 UTC (permalink / raw)
To: xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Xen-devel] pygrub not starting first menuentry in Fedora 30
2019-05-13 10:24 pygrub not starting first menuentry in Fedora 30 Steven Haigh
@ 2019-05-13 10:24 ` Steven Haigh
2019-05-14 13:40 ` George Dunlap
1 sibling, 0 replies; 6+ messages in thread
From: Steven Haigh @ 2019-05-13 10:24 UTC (permalink / raw)
To: xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: pygrub not starting first menuentry in Fedora 30
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
1 sibling, 2 replies; 6+ messages in thread
From: George Dunlap @ 2019-05-14 13:40 UTC (permalink / raw)
To: Steven Haigh; +Cc: xen-devel
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.
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.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] pygrub not starting first menuentry in Fedora 30
2019-05-14 13:40 ` George Dunlap
@ 2019-05-14 13:40 ` George Dunlap
2019-05-14 13:49 ` Steven Haigh
1 sibling, 0 replies; 6+ messages in thread
From: George Dunlap @ 2019-05-14 13:40 UTC (permalink / raw)
To: Steven Haigh; +Cc: xen-devel
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.
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.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: pygrub not starting first menuentry in Fedora 30
2019-05-14 13:40 ` George Dunlap
2019-05-14 13:40 ` [Xen-devel] " George Dunlap
@ 2019-05-14 13:49 ` Steven Haigh
2019-05-14 13:49 ` [Xen-devel] " Steven Haigh
1 sibling, 1 reply; 6+ messages in thread
From: Steven Haigh @ 2019-05-14 13:49 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] pygrub not starting first menuentry in Fedora 30
2019-05-14 13:49 ` Steven Haigh
@ 2019-05-14 13:49 ` Steven Haigh
0 siblings, 0 replies; 6+ messages in thread
From: Steven Haigh @ 2019-05-14 13:49 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-14 13:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-05-14 13:49 ` [Xen-devel] " Steven Haigh
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).