dcavalca / rpms / grub2

Forked from rpms/grub2 3 years ago
Clone

Blame SOURCES/0280-grub.d-Fix-boot_indeterminate-getting-set-on-boot_su.patch

ee2076
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
ee2076
From: Hans de Goede <hdegoede@redhat.com>
ee2076
Date: Tue, 26 Nov 2019 09:51:41 +0100
ee2076
Subject: [PATCH] grub.d: Fix boot_indeterminate getting set on boot_success=0
ee2076
 boot
ee2076
ee2076
The "grub.d: Split out boot success reset from menu auto hide script"
ee2076
not only moved the code to clear boot_success and boot_indeterminate
ee2076
but for some reason also mixed in some broken changes to the
ee2076
boot_indeterminate handling.
ee2076
ee2076
The boot_indeterminate var is meant to suppress the boot menu after
ee2076
a reboot from either a selinux-relabel or offline-updates. These
ee2076
2 special boot scenarios do not set boot_success since there is no
ee2076
successfull interaction with the user. Instead they increment
ee2076
boot_indeterminate, and if it is 1 and only when it is 1, so the
ee2076
first reboot after a "special" boot we suppress the menu.
ee2076
ee2076
To ensure that we do show the menu if we somehow get stuck in a
ee2076
"special" boot loop where we do special-boots without them
ee2076
incrementing boot_indeterminate, the code before the
ee2076
"grub.d: Split out boot success reset from menu auto hide script"
ee2076
commit would increment boot_indeterminate once when it is 1, so that
ee2076
even if the "special" boot reboot-loop immediately we would show the
ee2076
menu on the next boot.
ee2076
ee2076
That commit broke this however, because it not only moves the code,
ee2076
it also changes it from only "incrementing" boot_indeterminate once to
ee2076
always incrementing it, except when boot_success == 1 (and we reset it).
ee2076
ee2076
This broken behavior causes the following problem:
ee2076
ee2076
1. Boot a broken kernel, system hangs, power-cycle
ee2076
2. boot_success now != 1, so we increment boot_indeterminate from 0
ee2076
   (unset!) to 1. User either simply tries again, or makes some changes
ee2076
   but the end-result still is a system hang, power-cycle
ee2076
3. Now boot_indeterminate==1 so we do not show the menu even though the
ee2076
   previous boot failed -> BAD
ee2076
ee2076
This commit fixes this by restoring the behavior of setting
ee2076
boot_indeterminate to 2 when it was 1 before.
ee2076
ee2076
Fixes: "grub.d: Split out boot success reset from menu auto hide script"
ee2076
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ee2076
---
ee2076
 util/grub.d/10_reset_boot_success.in | 8 ++++----
ee2076
 1 file changed, 4 insertions(+), 4 deletions(-)
ee2076
ee2076
diff --git a/util/grub.d/10_reset_boot_success.in b/util/grub.d/10_reset_boot_success.in
ee2076
index 6c88d933dde..737e1ae5b68 100644
ee2076
--- a/util/grub.d/10_reset_boot_success.in
ee2076
+++ b/util/grub.d/10_reset_boot_success.in
ee2076
@@ -6,18 +6,18 @@
ee2076
 #
ee2076
 # The boot_success var needs to be set to 1 from userspace to mark a boot successful.
ee2076
 cat << EOF
ee2076
-insmod increment
ee2076
 # Hiding the menu is ok if last boot was ok or if this is a first boot attempt to boot the entry
ee2076
 if [ "\${boot_success}" = "1" -o "\${boot_indeterminate}" = "1" ]; then
ee2076
   set menu_hide_ok=1
ee2076
 else
ee2076
   set menu_hide_ok=0 
ee2076
 fi
ee2076
-# Reset boot_indeterminate after a successful boot, increment otherwise
ee2076
+# Reset boot_indeterminate after a successful boot
ee2076
 if [ "\${boot_success}" = "1" ] ; then
ee2076
   set boot_indeterminate=0
ee2076
-else
ee2076
-  increment boot_indeterminate
ee2076
+# Avoid boot_indeterminate causing the menu to be hidden more then once
ee2076
+elif [ "\${boot_indeterminate}" = "1" ]; then
ee2076
+  set boot_indeterminate=2
ee2076
 fi
ee2076
 # Reset boot_success for current boot 
ee2076
 set boot_success=0