Forced reboot ends up NOT triggering normal unit shutdown, but only
sends TERM signal, then KILL later. Some processes such as dmeventd
do not quit on receiving TERM signal (protected), which means they
are killed after a long delay by systemd using the KILL signal.
In case the normal reboot doesn't go through, "reboot.target" will be
triggered after a timeout and send the KILL signal anyway.
Resolves: rhbz#2093133
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This can be useful when user has this UEFI boot order e.g.:
Windows | grub | Linux
And decides to boot into grub/Linux. In case the autorelabel service
is being run after the boot into grub, then the reboot after the
autorelabel is done will cause user to boot into Windows again...
This change should make the behaviour more intuitive for the user.
Signed-off-by: David Kaspar [Dee'Kej] <dkaspar@redhat.com>
This code is currently incorrect. Currently redirecting `fixfiles` to
/dev/null will have very little effect. Two messages will be suppressed,
but both the percentage progress indicator, and any errors from
the setfiles/restorecon binary will still be shown.
The fact that fixfiles redirected its log output to stdin (!) was purely
an implementation artefact. It was used to write log messages even inside
shell functions whose output is captured e.g. `RESULT=$(shell_func)`.
When fixfiles is fixed to support output redirection normally, this code
would now behave incorrectly. It would suppress all percentage progress
messages for this long-running process.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
initscripts package is being slowly removed so fedora-autorelabel
utility and systemd unit files need a new home.
At the same time, "fedora-" prefix is changed to general "selinux-".
/lib/systemd/fedora-autorelabel -> /usr/libexec/selinux/selinux-autorelabel
fedora-autorelabel.service -> selinux-autorelabel.service
fedora-autorelabel-mark.service -> selinux-autorelabel-mark.service
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1328825
