Release criterion https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU Bug since Fedora 30 also affects Fedora 31 and has been proposed as a Fedora 31 blocker bug https://bugzilla.redhat.com/show_bug.cgi?id=1703700 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 https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/message/OCZUL7EDONHKNRVOVRIZBOLANMJNJHHF/ 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. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
