DevHeads.net

removing Xen from Fedora release criteria

Release criterion
<a href="https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU" title="https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU">https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU</a>

Bug since Fedora 30 also affects Fedora 31 and has been proposed as a
Fedora 31 blocker bug
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1703700" title="https://bugzilla.redhat.com/show_bug.cgi?id=1703700">https://bugzilla.redhat.com/show_bug.cgi?id=1703700</a>

The gist of this bug is that Bootloaderspec by default broke Xen from
working out of the box (i.e. install and reboot and it works, no user
intervention required). Basically the pygrub bootloader that Xen uses,
doesn't understand Bootloaderspec.

Upon reverting to the pre-BLS state, things are still broken for
reasons not yet well understood. When BLSCFG=false, and whether
grubby-deprecated is installed or not, a newly installed kernel causes
an entry to be added to grub.cfg using an extra /, i.e. //boot/vmlinuz
and //boot/initramfs and this extra slash causes the kernel to not be
found and so boot fails.

Test@ list proposal and discussion started in April to drop this
release criterion
<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/OCZUL7EDONHKNRVOVRIZBOLANMJNJHHF/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/OCZUL7EDONHKNRVOVRIZBOLANMJNJHHF/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.o...</a>

Some notes from the test@ thread:

- Is a followup thread to a similar question about Xen support in
Fedora in July 2017
- Most Fedora testers responding are in favor of dropping the criterion
- Xen wasn't tested the entire Fedora 30 cycle

A contrary perspective is:

- The release criterion is still in place, not yet dropped
- The above bug applies to Fedora 30 and Fedora 31, and is a
regression from Fedora 29 where it just worked, no postintsall work
was needed to get Fedora to work with Xen.
- The apparent direct cause for the breakage is the Bootloaderspec by
default feature in Fedora 30

Nevertheless, we can't block release indefinitely. We can't even
practically block a few weeks for such a bug. If this bug can get
fixed ASAP, and if there's enough commitment to support Xen on Fedora
going forward, I think it might be reasonable to keep the release
requirement. But otherwise it's just untenable. And even if the
release requirement goes away, I think this bug should get fixed.

How to fix it?

a) teach pygrub to how to support Bootloaderspec. this is probably out
of scope in the near term. Bootloader spec is simple, but the way
Fedora uses it isn't exactly per the upstream spec. Fedora's usage
depends on parsing grub.cfg, grubenv, and each bootloaderspec snippet.
That's possibly a bit rough for pygrub for now.

b) teach kernel package post-install script to just stomp on the
grub.cfg using grub2-mkconfig which writes out a whole new clean
grub.cfg; we know this works already as a work around but we aren't
sure what other use cases might be negatively impacted by this

c) figure out what exactly is adding this extra '/' and fix it.
Possibly grubb-deprecated package or maybe it's buried in a kernel
post-install script?

Options b and c do not address the regression caused by Bootloaderspec
by default, because Xen users will need to do a post-install
adjustment, manually, to revert to the pre-BLS behavior. (i.e. they
need to set /etc/default/grub GRUB_ENABLE_BLSCFG=false, and run
grub2-mkconfig to cause the BLSCFG false change to take effect. I'm
not sure how difficult it is to detect Xen in the installation
environment and set BLSCFG automatically for the user.

Anyway, option C is probably the least risky, but leaves a residual
post-install effort burden on the user to disable BLS by default.