nalika / rpms / grub2

Forked from rpms/grub2 2 years ago
Clone

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

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