From: Steven Haigh <netwiz@crc.id.au>
To: Xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] Fedora 30 and BLSCFG changes equals non-booting DomUs.
Date: Thu, 01 Aug 2019 01:06:33 +1000 [thread overview]
Message-ID: <1564585593.5750.1@crc.id.au> (raw)
Fedora 30 implemented Boot Loader Specification (BLS) by default for
all newly installed, and any upgraded systems.
This causes hell booting a DomU that is *not* configured as HVM - thus
fails when not using the bootloader from within the guest.
pygrub will always fail to boot these VMs.
Links:
Fedora change page:
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
Main Fedora BZ with lots of issues:
https://bugzilla.redhat.com/show_bug.cgi?id=1652806
My bug report on new kernels not appearing in generated grub.cfg files:
https://bugzilla.redhat.com/show_bug.cgi?id=1703700
So far, the only workaround is to install the 'grubby-depreciated'
package, set 'GRUB_ENABLE_BLSCFG=false' in /etc/default/grub, then
manually re-create the grub.cfg file via: grub2-mkconfig -o
/boot/grub/grub.cfg
Upon a newer kernel being installed, it may or may not appear in the
grub.cfg configuration - even with the above changes. As such, numerous
kernel upgrades later and your installed VM might not boot at all.
In numerous systems, I run grub2-mkconfig in /etc/rc.d/rc.local to
avoid a completely broken VM. Not ideal.
So, to start the discussion, with none of this currently being sent
upstream, this is a Fedora-ism. How to handle BLS enabled guests?
It also seems to be a Fedora problem with respect to kernel updates
still causing problems - but that's another issue.
Steven Haigh
📧 netwiz@crc.id.au 💻 https://www.crc.id.au
📞 +613 9001 6090 📱 +614 1293 5897
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
reply other threads:[~2019-07-31 15:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1564585593.5750.1@crc.id.au \
--to=netwiz@crc.id.au \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.