plymouth-switch-root-initramfs.service commands plymouth to release
rootfs to allow the shutdown ramfs to unmount rootfs. However, it only
integrates with dracut. Arch Linux uses mkinitcpio by default, and it
uses shutdown ramfs when layered block storage (e.g. LUKS) is used for
rootfs. Therefore, it fails to unmount rootfs on shutdown if LUKS and
plymouth are used together.
Add a new trigger for plymouth-switch-root-initramfs.service to start
when /run/initramfs/shutdown exists (/run/initramfs/bin/sh may not exist
with mkinitcpio when systemd-based initramfs is used), and add a
dependency to start it after mkinitcpio generates the shutdown ramfs.
Add a plymouth-switch-root-initramfs.service, which will call
"plymouth update-root-fs --new-root-dir=/run/initramfs" to switch back
to the initramfs (when applicable).
Systemd will run this service before plymouthd receives the SIGTERM on
shutdown, so this will cause the plymouthd-fd-escrow helper to run
from the initramfs.
This avoids the plymouthd-fd-escrow helper keeping the rootfs busy.
Changes by Hans de Goede:
- Fix a couple of typos
- Add Conflicts=dracut-shutdown.service to plymouth-switch-root-initramfs.service
dracut-shutdown.service restores the initramfs when it is _stopped_
use Conflicts to make sure its ExecStop has run before we do
- Add a check for switching back to the initramfs to on_newroot () and dump
the debug-buffer before the switch (while we still have access to /var/log).
- Also add plymouth-switch-root-initramfs.service to kexec.target.wants.
kexec.target.wants uses --mode=shutdown, so the plymouthd-fd-escrow helper
will run, so we need to switch to the initramfs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
KillMode=none is deprecated, so we need to stop using it.
For now, use `KillMode=mixed` and `IgnoreOnIsolate=true` instead.
In the future, we should change plymouth to be able to exit and
start again without restarting the active animation, but that's
going to require some effort.
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/123
All plymouth's systemd unit files are meant to only run once, either during
boot or during shutdown/restart.
Certain events cause systemd to recheck the dependency try between systemd
units. Systemd had a bug before the 245 release which caused this check to
sometimes not restart exited services for which the dependencies are met.
Systemd 245 fixes this, this is causing problems with plymouth.
When the conditions are met for systemd to recheck the dependencies;
and the plymouthd started by plymouth-start.service has exited;
then systemd will restart the plymouth-start unit, causing plymouthd to
take over tty1 after boot. This is causing various problems, also see:
https://bugzilla.redhat.com/show_bug.cgi?id=1803293
Since all plymouth's systemd units are intended to run only once, they
all should be marked as remaining after exit by adding:
"RemainAfterExit=yes" to them. This causes systemd to still consider them
running after e.g. plymouthd has exited, as long as they have started
successfully. This fixes systemd restarting plymouth's units when it
should not do so.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1803293
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1807771
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Use @plymouthruntimedir@/pid in systemd-ask-password-plymouth.service.in so
that the way the path to the pidfile is build there is identical to the
way the --pidfile argument is build in plymouth-start.service.in.
Fixes#26
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some themes show certain text strings to the user depending on the mode,
see e.g. the shutdown vs reboot mockups of:
https://wiki.gnome.org/Design/OS/BootProgress
Besides during shutdown vs reboot, we also want different theming for
installing offline (security) updates versus doing an offline OS upgrade.
To make this possible this commit adds new reboot and system-upgrade
modes which can be specified either when starting plymouthd, or through
plymouth change-mode --<mode>.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When running in a container with plymouth installed, plymouth is started
unnecessarily and systemd prints warnings:
[ OK ] Reached target Shutdown.
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Process 253 (plymouthd) has been been marked to be excluded from killing. It is running from the root file system, and thus likely to block re-mounting of the root file system to read-only. Please consider moving it into an initrd file system instead.
It makes little sense to start plymouth in contains, so add
'ConditionVirtualization=!container' everywhere where
ConditionKernelCommandLine=!plymouth.enable=0 appears to disable plymouth
in containers.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1337611
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/plymouth/plymouth/issues/27
plymouthd currently sticks around on the main filesystem during
shutdown, while shutdown proceeds on the initramfs.
This commit adds a unit to make it jump into the initramfs too.
This is important, so we can run the drm escrow binary from
the initramfs.
This reverts commit 7adb50c267.
The .service files are already statically enabled, adding the Install
section and the WantedBy option is useless
Conflicts:
systemd-units/plymouth-quit-wait.service.in
https://bugs.freedesktop.org/show_bug.cgi?id=80048
plymouth-quit-wait.service is a synchronization point that
other services tie into, so they know when boot is finished
and the splash is down.
Unfortunately, in cases where the boot stalls, the last thing
users see is:
Starting Wait for Plymouth Boot Screen to Quit...
and then assume the problem is with the boot splash.
This commit makes the description less finger-pointy.
We need to make sure udevd is started before plymouthd since we
need to know that "queue is empty" means "coldplug complete" not
"coldplug hasn't started yet".
Since we're monitoring udev explicitly now, we have no
need to block the client show-splash request until graphics
devices settle.
This commit removes the udevadm calls from plymouth-start.service.
<haraldh> halfline, can you add plymouth-start.service to
plymouth-populate-initrd ??
<halfline> haraldh: sure, can you give me details on the bug its fixing?
<haraldh> except, if you put yourself out of the plymouth cgroup
<haraldh> and the "@" in argv[0][0]
<haraldh> better put plymouth-start.service in the
initrd-switch-root.target
<haraldh> easier
<halfline> well we already do the "@" in argv[0][0]
<halfline> and we already put KillMode=none SendSIGKILL=no in the
service file
<halfline> but will add the change
<haraldh> hmm, ok
It's possible to get in a state where plymouthd is
started in the initrd but not displayed. In the
event this happens, we'll neglect to ever show it,
since it already has a pid file.
plymouthd is now hardened against getting called
multiple times, so we no longer need to protect it
at the systemd level.
This commit drops the
ConditionPathExists=!@plymouthruntimedir@/pid
line from the systemd service file, so we always
call plymouthd from the main fs and always call
plymouth show-splash.
the initrd hits the local-fs.target as part of its normal
boot process. We used to use local-fs.target as a way of
knowing the system / is read-write. This no longer is a
valid mechanism.
This commit:
1) Stops installing plymouth-read-write service in the initrd
2) Makes it so if it does end up in the initrd it won't be
used
Related to fedora bug 830482
systemd tries to bring down the world when going from
the initramfs to /
commit 9e5a276f32 tried
to prevent plymouthd from getting killed by settings
argv[0][0] to @
This isn't seemingly sufficient. Throw some lines into
the plymouth-start service file that should hopefully help.
The previous systemd commit introduced a file named
systemd-ask-password-plymouth.path.in
The makefile was only looking for .service.in files
when stripping the .in suffix, so it got installed
incorrectly.
This commit fixes up the Makefile.
When plymouth service files were moved from systemd to plymouth
two files got lost in the shuffle.
This commit adds them.
http://bugzilla.freedesktop.org/51573
The udev trigger calls that are there, are actually
spurious. udev will coldplug those subsystems at
start up anyway, so doing it explicitly is wrong.
This commit drops those trigger calls.
What does matter is the udevadm settle call. It's
what makes things block until the graphics driver
is loaded.
udevadm settle is a big sledgehammer, though. It blocks
until all the triggered events (even stuff unrelated to
graphics) are finished.
This commit adds a --exit-if-exists argument to udevadm settle,
so it will bail early as soon as the graphics devices
are up.
plymouth-start.service does this sort of hacky
"udevadm trigger" stuff before doing plymouth show-splash,
to ensure plymouth show-splash is called after the
graphcis subsystem is up.
It actually does two calls:
- one call that triggers any pci devices with the class
0x030000 (which is "vga compatible display device")
- another call that triggers the gpu subsystem
The first call is borrowed from dracut:
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=2c02c8318
and I can't find any historical context on why its needed. As I
understand things, the latter should be a superset of the former.
Furthermore, the first trigger is missing a --subsystem-match=pci call
so it's matching the "class" attribute in every subsystem, which is slow.
I'm going to drop the first trigger until I start hitting problems
and need to add it back.
plymouth-start.service does this sort of hacky
"udevadm trigger" call before doing plymouth show-splash,
to ensure plymouth show-splash is called after the
graphcis subsystem is up. Because this udev trigger call
only passes --subsystem-match calls with no corresponding
--subsystem call, it will trawl through all subsystems in
/sys rather than just the pci subsystem (where all the matches
are guaranteed to be).
This commit adds --subsystem=pci to stop doing that extra work.
All of this will eventually be replaced with plymouthd either
listening for the udev events itself (or potentially logind,
if logind gains a way to tag a "graphics" capability on a seat).
