This series of patches is to improve the parsing by pygrub of grub
configuration on Fedora. The current result of parsing is generally
that the second kernel listed is set as the default due to a
set default=1 line in grub.cfg which is only intended to be
reached after repeated boot failures.

The patches read the grubenv file (which consists of key=value lines
padded to 1024 characters by # characters) to get the values of
next_entry and saved_entry, which can be a kernel string or an
order number. Unfortunately, for Fedora 31 at least, this is
often a BLS-style string so it isn't necessarily useful. The patches
use the value of next_entry or of saved_entry to set the default
kernel or sets it to the first kernel listed if those values are set
but not used.


Michael Young (3):
  set default kernel from grubenv next_entry or saved_entry
  read a grubenv file if it is next to the grub.cfg file
  Example Fedora 31 grub.cfg and grubenv files

 tools/pygrub/examples/fedora-31.grub.cfg | 200 +++++++++++++++++++++++
 tools/pygrub/examples/fedora-31.grubenv  |   5 +
 tools/pygrub/src/GrubConf.py             |  31 +++-
 tools/pygrub/src/pygrub                  |  21 ++-
 4 files changed, 253 insertions(+), 4 deletions(-)
 create mode 100644 tools/pygrub/examples/fedora-31.grub.cfg
 create mode 100644 tools/pygrub/examples/fedora-31.grubenv

-- 
2.21.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On 2019-10-26 09:52, YOUNG, MICHAEL A. wrote:
> This series of patches is to improve the parsing by pygrub of grub
> configuration on Fedora. The current result of parsing is generally
> that the second kernel listed is set as the default due to a
> set default=1 line in grub.cfg which is only intended to be
> reached after repeated boot failures.
> 
> The patches read the grubenv file (which consists of key=value lines
> padded to 1024 characters by # characters) to get the values of
> next_entry and saved_entry, which can be a kernel string or an
> order number. Unfortunately, for Fedora 31 at least, this is
> often a BLS-style string so it isn't necessarily useful. The patches
> use the value of next_entry or of saved_entry to set the default
> kernel or sets it to the first kernel listed if those values are set
> but not used.
> 
> 
> Michael Young (3):
>   set default kernel from grubenv next_entry or saved_entry
>   read a grubenv file if it is next to the grub.cfg file
>   Example Fedora 31 grub.cfg and grubenv files
> 
>  tools/pygrub/examples/fedora-31.grub.cfg | 200 +++++++++++++++++++++++
>  tools/pygrub/examples/fedora-31.grubenv  |   5 +
>  tools/pygrub/src/GrubConf.py             |  31 +++-
>  tools/pygrub/src/pygrub                  |  21 ++-
>  4 files changed, 253 insertions(+), 4 deletions(-)
>  create mode 100644 tools/pygrub/examples/fedora-31.grub.cfg
>  create mode 100644 tools/pygrub/examples/fedora-31.grubenv

Tested-by: Steven Haigh <netwiz@crc.id.au>

No issues located, seems to work with F31 guests as advertised.

I believe these would be candidates for backports into other supported 
Xen versions as well.

-- 
Steven Haigh

? netwiz@crc.id.au     ? http://www.crc.id.au
? +61 (3) 9001 6090    ? 0412 935 897

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Just for the record, the grub packages have been updated in Fedora 31 
to automatically disable BLS when installing / removing a kernel on Xen 
Dom0 / DomU installations.

As such, we should never come across a Fedora 31 install with BLS 
enabled from this point forwards.

There is currently ongoing work to disable BLS during the installation 
via anaconda - but this hasn't hit yet - and I believe it's already a 
freeze exception.

If / when pygrub is able to properly read and boot from BLS based 
configurations (I'm not sure if this patchset makes pygrub BLS 
compatible, or just fixes the existing issues) - but we can look at 
revisiting removing these workarounds from anaconda / grub2 packages in 
F30 / F31 / Rawhide.

Steven Haigh

📧 netwiz@crc.id.au     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897


On Fri, Oct 25, 2019 at 22:52, "YOUNG, MICHAEL A." 
<m.a.young@durham.ac.uk> wrote:
> This series of patches is to improve the parsing by pygrub of grub
> configuration on Fedora. The current result of parsing is generally
> that the second kernel listed is set as the default due to a
> set default=1 line in grub.cfg which is only intended to be
> reached after repeated boot failures.
> 
> The patches read the grubenv file (which consists of key=value lines
> padded to 1024 characters by # characters) to get the values of
> next_entry and saved_entry, which can be a kernel string or an
> order number. Unfortunately, for Fedora 31 at least, this is
> often a BLS-style string so it isn't necessarily useful. The patches
> use the value of next_entry or of saved_entry to set the default
> kernel or sets it to the first kernel listed if those values are set
> but not used.
> 
> 
> Michael Young (3):
>   set default kernel from grubenv next_entry or saved_entry
>   read a grubenv file if it is next to the grub.cfg file
>   Example Fedora 31 grub.cfg and grubenv files
> 
>  tools/pygrub/examples/fedora-31.grub.cfg | 200 
> +++++++++++++++++++++++
>  tools/pygrub/examples/fedora-31.grubenv  |   5 +
>  tools/pygrub/src/GrubConf.py             |  31 +++-
>  tools/pygrub/src/pygrub                  |  21 ++-
>  4 files changed, 253 insertions(+), 4 deletions(-)
>  create mode 100644 tools/pygrub/examples/fedora-31.grub.cfg
>  create mode 100644 tools/pygrub/examples/fedora-31.grubenv
> 
> --
> 2.21.0
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On Sat, 26 Oct 2019, Steven Haigh wrote:

> If / when pygrub is able to properly read and boot from BLS based 
> configurations (I'm not sure if this patchset makes pygrub BLS compatible, or 
> just fixes the existing issues) - but we can look at revisiting removing 
> these workarounds from anaconda / grub2 packages in F30 / F31 / Rawhide.

The patchset doesn't add BLS compatibility but should be useful for what I 
expect BLS support to look like (I have a idea of what would be required 
though I haven't worked out the details yet).

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Awesome - thanks Michael.

I'll try and test this out tomorrow.
Steven Haigh

📧 netwiz@crc.id.au     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897


On Sat, Oct 26, 2019 at 16:00, "YOUNG, MICHAEL A." 
<m.a.young@durham.ac.uk> wrote:
> On Sat, 26 Oct 2019, Steven Haigh wrote:
> 
>>  If / when pygrub is able to properly read and boot from BLS based
>>  configurations (I'm not sure if this patchset makes pygrub BLS 
>> compatible, or
>>  just fixes the existing issues) - but we can look at revisiting 
>> removing
>>  these workarounds from anaconda / grub2 packages in F30 / F31 / 
>> Rawhide.
> 
> The patchset doesn't add BLS compatibility but should be useful for 
> what I
> expect BLS support to look like (I have a idea of what would be 
> required
> though I haven't worked out the details yet).
> 
>  	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel