From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Hans de Goede <hdegoede@redhat.com>

Date: Tue, 26 Nov 2019 09:51:41 +0100

Subject: [PATCH] grub.d: Fix boot_indeterminate getting set on boot_success=0

 boot

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

The "grub.d: Split out boot success reset from menu auto hide script"

not only moved the code to clear boot_success and boot_indeterminate

but for some reason also mixed in some broken changes to the

boot_indeterminate handling.

The boot_indeterminate var is meant to suppress the boot menu after

a reboot from either a selinux-relabel or offline-updates. These

2 special boot scenarios do not set boot_success since there is no

successfull interaction with the user. Instead they increment

boot_indeterminate, and if it is 1 and only when it is 1, so the

first reboot after a "special" boot we suppress the menu.

To ensure that we do show the menu if we somehow get stuck in a

"special" boot loop where we do special-boots without them

incrementing boot_indeterminate, the code before the

"grub.d: Split out boot success reset from menu auto hide script"

commit would increment boot_indeterminate once when it is 1, so that

even if the "special" boot reboot-loop immediately we would show the

menu on the next boot.

That commit broke this however, because it not only moves the code,

it also changes it from only "incrementing" boot_indeterminate once to

always incrementing it, except when boot_success == 1 (and we reset it).

This broken behavior causes the following problem:

1. Boot a broken kernel, system hangs, power-cycle

2. boot_success now != 1, so we increment boot_indeterminate from 0

   (unset!) to 1. User either simply tries again, or makes some changes

   but the end-result still is a system hang, power-cycle

3. Now boot_indeterminate==1 so we do not show the menu even though the

   previous boot failed -> BAD

This commit fixes this by restoring the behavior of setting

boot_indeterminate to 2 when it was 1 before.

Fixes: "grub.d: Split out boot success reset from menu auto hide script"

Signed-off-by: Hans de Goede <hdegoede@redhat.com>

[jpokorny: 01_menu_auto_hide.in: fix a then/than typo]

Signed-off-by: Jan Pokorný <jpokorny@fedoraproject.org>

Signed-off-by: Robbie Harwood <rharwood@redhat.com>

---

 util/grub.d/10_reset_boot_success.in | 8 ++++----

 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/util/grub.d/10_reset_boot_success.in b/util/grub.d/10_reset_boot_success.in

index 6c88d933dd..e73f4137b3 100644

--- a/util/grub.d/10_reset_boot_success.in

+++ b/util/grub.d/10_reset_boot_success.in

@@ -6,18 +6,18 @@

 #

 # The boot_success var needs to be set to 1 from userspace to mark a boot successful.

 cat << EOF

-insmod increment

 # Hiding the menu is ok if last boot was ok or if this is a first boot attempt to boot the entry

 if [ "\${boot_success}" = "1" -o "\${boot_indeterminate}" = "1" ]; then

   set menu_hide_ok=1

 else

   set menu_hide_ok=0 

 fi

-# Reset boot_indeterminate after a successful boot, increment otherwise

+# Reset boot_indeterminate after a successful boot

 if [ "\${boot_success}" = "1" ] ; then

   set boot_indeterminate=0

-else

-  increment boot_indeterminate

+# Avoid boot_indeterminate causing the menu to be hidden more than once

+elif [ "\${boot_indeterminate}" = "1" ]; then

+  set boot_indeterminate=2

 fi

 # Reset boot_success for current boot 

 set boot_success=0