Created attachment 1452558 [details]
[PATCH 1/2] selinux-autorelabel: Use plymouth --quit rather then --hide-splash

Hi,

Here are 2 patches (to apply on a fedpkg clone) with 1 fix for and 1 improvement to the selinux-autorelabel script:

[PATCH 1/2] selinux-autorelabel: Use plymouth --quit rather then --hide-splash

plymouth by defaults waits for 5 seconds before showing the splash so
that the splash simply gets skipped on real quick boots.

In my testing it seems that --hide-splash is a no-op when run before
the 5 seconds have passed and the splash is shown, causing the splash
to still be there during a relabel. Note this problem only shows when
*not* using disk-encryption.

Switching to plymouth --quit fixes this.

[PATCH 2/2] selinux-autorelabel: Increment boot_indeterminate grub environment variable

For the new grub auto-hide feature:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

Grub needs to know if the previous boot succeeded. This is tracked
through flags in the grub environment.

A selinux autorelabel is special, because it reboots the machine without
completing the boot in the normal manner.

grub checks the (new) boot_indeterminate grub environment variable to deal
with this. This is a variable containing a count of special boots since
the last successful normal boot. If this variable is 1 then it also treats
the previous boot as successful. The idea is that an autorelabel (or
offline updates) increments boot_indeterminate, so normally after a reboot
it will be 1 and the grub menu stays hidden. But if we end up in a selinux
autorelabel loop for some reason, then it will be bigger then 1 (*) and
the grub menu will be shown allowing the user to try and fix things.

*) grub itself will also increment it if it is 1 so that even if it gets
incremented only once, that still only makes 1 boot count as successful.

This commit makes the selinux-autorelabel script call:
grub2-editenv - incr boot_indeterminate
for proper integration with this new grub feature.

###

Note I've not added .spec file changelog entries, since those just tend to get in the way of being able to cleanly apply the patches. The patch subjects are probably good candidates for specfile changelog entries.

Regards,

Hans