Further looking into this, it seems the problem occurs on this section
of the grub.cfg:
### BEGIN /etc/grub.d/08_fallback_counting ###
insmod increment
# Check if boot_counter exists and boot_success=0 to activate this
behaviour.
if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
# if countdown has ended, choose to boot rollback deployment,
# i.e. default=1 on OSTree-based systems.
if [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
set default=1
set boot_counter=-1
# otherwise decrement boot_counter
else
decrement boot_counter
fi
save_env boot_counter
fi
### END /etc/grub.d/08_fallback_counting ###
It seems pygrub sees the 'set default=1' and uses it - even though it
shouldn't be normally hit due to it being in a conditional.
Steven Haigh
📧 net...@crc.id.au 💻 https://www.crc.id.au
📞 +613 9001 6090 📱 +614 1293 5897
On Thu, Aug 1, 2019 at 12:54 AM, Steven Haigh <net...@crc.id.au> wrote:
There's a ton of changes to grub in Fedora 30.... Most of them
causing pain.
When booting using pygrub, the presented menu always has the second
option selected.
The contents of /etc/default/grub is as follows:
GRUB_TIMEOUT=1
GRUB_DEFAULT=0
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="audit=0 selinux=0 console=hvc0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=false
I have attached the generated grub.cfg created via:
grub2-mkconfig -o /boot/grub/grub.cfg
BLSCFG is a whole new clusterf**k of problems that became default in
Fedora 30 that cause many problems - but first things first...
Steven Haigh
📧 net...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
