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

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