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

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