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

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