Before this commit plymouth-populate-initrd was only recursively copying the
/usr/share/plymouth/themes/$PLYMOUTH_THEME_NAME to the initrd, assuming
that ImageDir will point there.
This makes it impossible for 2 themes to share their ImageDir, which is
desirable for example for the spinner and bgrt themes, which use the same
images with slightly different settings.
This commit also makes plymouth-populate-initrd also copy the ImageDir
if it is different from the theme-dir, making it possible for ImageDir
to point to a different dir.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Not all distros use the upstream plymouth-populate-initrd
script to populate their initramfs. As a consequence,
some themes have been developed that use subdirectories,
(which is not supported by plymouth-populate-initrd).
This commit adds support for that feature, so that
preexisting themes get properly installed.
https://bugs.freedesktop.org/show_bug.cgi?id=103424
If you set PLYMOUTH_THEME_NAME to override the theme in an initrd
(as e.g. lorax does when building upgrade.img), plymouth-populate-initrd
tries to edit plymouthd.conf to enable that theme.
Unfortunately, the existing `sed` line doesn't work if your
plymouthd.conf is empty or all commented out - which is how we currently
ship it.
So before modifying the config, make sure it has a [Daemon] section
header, and a Theme=[placeholder] line for us to modify.
Resolves: RHBZ#1223344
Some themes like to keep their content in subfolders,
but plymouth-populate-initrd currently fails to copy
those subfolders over to the initrd.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=94883
If plymouth is configured --with-system-root-install=no then the
systemd unitd files will write the paths of plymouth and plymouthd
relative to /usr . The script currently hardcodes installing them
to the initrd's /
This commit makes sure they get placed on the same part of the of
the initrd filesystem as systemd expects to find them.
https://bugs.freedesktop.org/show_bug.cgi?id=74174
plymouth-update-initrd is a script that should probably be eventually
dropped. It was originally created to unpack and initrd and graft
plymouth in. Later, it just became a thin wrapper around mkinitrd.
These days, very few (any?) distros use mkinitrd. Change it to call
dracut instead.
Relevant irc log:
<newfo> this is SO WRONG:
http://cgit.freedesktop.org/plymouth/tree/scripts/plymouth-update-initrd
<newfo> it won't work on any distro
<newfo> would you mind updating that please?
<newfo> replace the mkinitrd line in
/usr/libexec/plymouth/plymouth-update-initrd to dracut -f
/boot/initramfs-$(uname -r).img $(uname -r)
<-- newfo has quit (Client Quit)
<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
You can set PLYMOUTH_THEME_NAME when building initramfs to get a
different theme into initramfs, but this doesn't change the default
theme, so the resulting initramfs won't actually use the theme we
installed.
This patch makes plymouth-populate-initrd rewrite the 'Theme=XXX' line
in plymouthd.conf, so plymouth will use the theme we install.
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
Having the dependency is awkward and causes problems, so
don't bother.
This commit just copy and pastes the relevant bits for
inst().
Ideally, this would be an installroot command implemented in
C in util-linux, but shrug
This patch adds the respective configure options to make it possible to
disable libdrm_intel, libdrm_radeon, libdrm_nouveau, and libkms
independently from each other.
https://bugs.freedesktop.org/show_bug.cgi?id=29804
The logofile by default is $datadir/plymouth.png
$datadir contains a reference to $datarootdir, so
we need to preexpand the variable in configure, for
the right value to get written to plymouth-populate-initrd.
When not installing in system root, the populate initrd script would not
install the client or daemon due to the paths being hardcoded.
Environmental variables are also now available to override the defaults.
The set-default-theme script was incorrectly redirecting
stderr from a grep command to /null instead of /dev/null.
This causes a /null file to get created on the filesystem.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=30576
Reported by: David LeBlanc <leblancdw@yahoo.com>
Because of an apparent think-o in the script, if a custom theme
has a broken symlink in it, plymouth-populate-initrd would silently
stop processing files and ship an incomplete set of data files.
This commit changes "break" to "continue" so that broken symlinks
are ignored, which was probably the original intent.
It's important to make sure the theme name is properly
quoted when passed to the basename command. This
is because, if the theme name is empty we want the empty
string returned, not the suffix that would otherwise be
stripped off.
Some discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=606634
Now that the daemon looks for the default theme in configuration
files, we should make plymouth-set-default-theme write the
configuration files instead of doing symlinks.
That's what this commit does.
The scripts hard-coded the paths for LIBEXECDIR and DATADIR, unless
passed as environment variables. Instead of doing this, which breaks
if plymouth is installed outside of /usr, set these derived from the
configure $libexecdir and $datadir variables just as we do for
pkg-config, etc.
Since we use so many variables, it makes more sense to generate these
scripts from config.status rather than having special Makefile rules
for them.
Splashes aren't just shown for "boot" so including "boot" in
the name isn't right. Also, right now we link against libpng
even if we don't have any splash that uses it. This is the first
step toward making libpng only get linked to graphical splashes.
We'll need to move the graphical bits to their own library to
complete the process.
When running new, unfamiliar commands I usually invoke them with
--help to see what options they have. For plymouth-set-default-theme,
there is no --help option which I find a bit confusing, especially
since the usage is not straight-forward.
There is now an additional function "show_help" which displays an
help output when invoking plymouth-set-default-theme with --help.
Much of this code comes directly from ply-frame-buffer in libply,
but shoehorned to fit into the renderer plugin interface.
One improvement over the old code is it tracks VT changes, and
stops drawing when the wrong VT is active.
We've been using the inst function provided by mkinitrd
to install plymouth and its dependencies into the initrd
root, but mkinitrd may not be installed in a dracut world,
and dracut has its own inst function.
This commit tries getting access to either of them, before
bailing. At some point we may want to bundle our own inst
function or get a new flag added to /usr/bin/install to do
what inst does.
One useful way to use plymouth is by installing it into
an auxillary initrd image, that overlays the primary one.
This allows plymouth and its current theme to get updated
indepedently of the kernel and the rest of the initrd
stuff.
plymouth-generate-initrd creates an initrd named:
initrd-plymouth.img
in /boot that is suitable for use a second initrd on
the initrd line in grub.conf.
Previously, we'd try to guess the plugin path based
on the arch of the running process. That's sort of
fragile, so better to just install plugins where
plymouth says it's going to look for them.
Some of the plugins (well, the glow plugin) would be a lot more
versatile if they could be reused for multiple splashes with different
images.
This commit splits boot splashes into two parts, the plugin engine which
does all the dirty work, and the theme which says which plugin to use
and optionally how the plugin should work (using plugin specific
key/value pairs)
