Project Plymouth

Plymouth is the codename for a project started in 2007 by Ray Strobe of Redhat to develop a graphical application to display a flicker free animated splash screen during the boot process while logging console text output to a log file. Fedora 10 (Cambridge) was the first release of Fedora to contain Plymouth. Development work is actively ongoing and the current release is 0.71.

Plymouth is intended to be a replacement for RHGB (Red Hat Graphical Boot) which is currently used by Red Hat to provide a graphical boot display. If rhgb is part of the kernel command line, rhgb is started early in the boot process by /etc/sysinit. rhgb starts an X server for display :1 on one virtual terminal so that it avoids conflict with the regular X server which may be starting for display :0 on another virtual terminal. It also creates a Unix domain socket (/etc/rhgb/temp/rhgb-socket) so that boot scripts can communicate with it. As boot scripts execute, they can use rhgb-client to send messages to rhgb, which then updates the text and progress display. When the system is finished booting, rhgb-client is invoked with the –quit option to send a terminate request to rhgb. The user is then switched to the X server used by the display manager. Unfortunately the sequence of switching from text mode to rhgb‘s X server to text mode to the display manager’s X server can cause significant screen flickering. Another major drawback of rhgb is that boot messages are not logged.

The main objective behind Plymouth is to provide a flicker free system booting experience where as Ray Strode put it “the ugly details of boot up” are hidden behind a graphical (and possibly animated) splash screen. A secondary objective is to log the boot sequence. Plymouth is designed to work on systems with direct rendering manager (DRM) kernel modesetting (KMS) drivers. DRM is a component of the Direct Rendering Infrastructure project. It consists of two kernel modules, a generic DRM driver, and another which has support for the specific graphics card hardware. This pair of drivers allows a userspace client direct access to the graphics card hardware. See here for further information on DRM mode setting. Thus very early on in the boot process the optimal native video display mode for the system is set by a kernel mode setting driver. In turn Plymouth uses that mode, and that mode remains the same during the entire boot process up to and after an X server starts. The X server, when started, takes over the existing mode, virtual terminals and framebuffer content. The availability of a kernel modesetting driver is the key enabler for Plymouth. However, for systems without kernel modesetting drivers, there is a fallback text mode which is the familiar tricolor blue/white/black progress bar. Plymouth also drops back to this text mode if the default plugin fails for whatever reason.

Kernel modesetting drivers are still in active development and somewhat buggy. As of Fedora 11, only Radeon R500 and higher series graphics cards support kernel modesetting by default. There is work in progress to provide kernel modesetting support for R100 and R200 graphics cards. Intel kernel modesetting drivers exist but are not turned on by default. Support for kernel modesetting in the nVidia graphic cards via the Nouveau driver is still experimental. If you end up with nothing but a black screen during boot up, or a screen with nothing but random noise on it, try adding nomodeset to the kernel command line to disable kernel mode setting.

If there is no suitable kernel modesetting driver available for your particular graphics card or you want to set an explicit mode, you can add the string vga=XXX to the kernel command line. The kernel command line option vga=ask invokes the the built-in vesa framebuffer driver, displays a list of supported modes and asks you to select a mode. It then boots the kernel using this mode. The kernel command line option vga=mode, where mode is either a 4 digit hexadecimal with a leading zero and no letter ‘x’ or a 3 digit decimal number, enables you to set a specific mode.

How can you tell what particular modes are available and which will work best for you? This really depends on the type of graphics card that you have in your system, and the amount of video memory available. The only way is to experiment with different modes.

The following table shows the mode numbers you can input at the vga= prompt using hexadecimals


and here is the same table using decimal numbers.

Note that 8 bits = 256 colors, 15 bits [5:5:5] = 32,768 colors, 16 bits [5:6:5] = 65,536 colors and 24 bits [8:8:8] = 16.8 million colors. Additional modes are at the discretion of the graphics card manufacturer, as the VESA 2.0 specification only defines modes up to 0x31F. For more information about VESA modes, see this article about VESA BIOS Extension compliant graphic cards.

Plymouth works with themes which are analogous to screensavers that are displayed at boot time. Fedora 11 shipped with three graphical themes solar, fade-in and spinfinity, and two non-graphical themes text and details. The text theme is the default theme which is displayed if another theme fails for whatever reason.

The terminology and technology around themes and plugins has evolved as the project progressed. The version of Plymouth that shipped in Fedora 10 was based on a plugin system where each splash screen had to be coded from scratch. This problem was recognized and for Fedora 11 Plymouth went through a major rewrite whereby it now supports themes which in turn use standard plugins. Thus theme developers can now focus on the theme graphics rather than having to do raw coding.

Currently there are five themes in the Fedora repositories. Charge is the default theme for Fedora 11 (Leonidas). Spinfinity is a throbber that moves in a path shaped like the infinity sign. Fade-In shows the Fedora logo fading in and out in a star field. details shows the classic scrolling output from the boot process. text is the fallback bottom of the screen tricolor theme. Solar, my personal favorite to date, and the default theme for Fedora 10, is not installed in Fedora 11 by default but is in an optional package. It displays a planet with exploding pulsars.

To install all the Plymouth themes in the Fedora repositories:

# yum -y install plymouth-theme-*

Installed Plymouth themes can be listed use the plymouth-set-default-theme script:

# /usr/sbin/plymouth-set-default-theme --list

Theme files are stored in the /usr/share/plymouth/themes subdirectory.

# ls /usr/share/plymouth/themes/
charge  default.plymouth  details  fade-in  spinfinity  text

Note that default.plymouth is a symbolic link to the actual designed default theme.

There are two types of plugins: splash and control. There can only be one splash plugin in use at a time. A splash plugin is what draws the splash screen, asks for a password, displays messages, and more. A theme calls a splash plugin to do the actual work. For example, here is a listing of the files associated with the charge theme.

$ ls /usr/share/plymouth/themes/charge
box.png          progress-01.png  progress-07.png  progress-13.png  throbber-00.png  throbber-06.png  throbber-12.png
bullet.png       progress-02.png  progress-08.png  progress-14.png  throbber-01.png  throbber-07.png  throbber-13.png
charge.plymouth  progress-03.png  progress-09.png  progress-15.png  throbber-02.png  throbber-08.png  throbber-14.png
entry.png        progress-04.png  progress-10.png  progress-16.png  throbber-03.png  throbber-09.png  throbber-15.png
lock.png         progress-05.png  progress-11.png  progress-17.png  throbber-04.png  throbber-10.png
progress-00.png  progress-06.png  progress-12.png  progress-18.png  throbber-05.png  throbber-11.png

The theme configuration file that is read by plymouthd is the name of the theme with a .plymouth extension. In this case it is charge.plymouth.

$ cat /usr/share/plymouth/themes/charge/charge.plymouth
[Plymouth Theme]
Description=A theme that features the shadowy hull of a Fedora logo charge up and and finally burst into into full form.


This theme calls the two-step plugin to do the actual work of displaying the theme. The two-step plugin expects a certain number and type of image files with specific names. Various directives can be passed to plugins; the number and type being plugin specific. For example different type of transitions can be specified for the two-step plugin using the Transition directive, i.e. fade-over, cross-fade and merge-fade.

Some plugins did not ship with Fedora 11. One such plugin is the label plugin. It is not part of initrd but is loadable once the root filesystem is mounted. It is implicitly loaded when a splash plugin attempts to display text. After label is loaded, it uses pango and cairo to handle message localization.

Another such plugin is script which supports a scripting language for themes. It supports two basic objects, i.e. Image and Sprite. If you are familiar with Javascript or the C language you should be comfortable with the syntax and idiom. Note that the scripting language is undergoing rapid development at present with a view to making it more object orientated so you may have to read the git logs or the source code to figure out what is or is not supported.

For examples of scripted themes, I recommend you look at the sources for the Vizta or the Dandelion themes. These themes were both developed by Charlie Brej, a research assistant at the University of Manchester UK, who is the main developer behind the scripting language. If you want to try these themes out on Fedora 11, you will have to import the sources from the Plymouth Git tree, configure, rebuild and install on your system.

The two main binaries involved in Plymouth are /sbin/plymouthd, a daemon that does most of the actual work by displaying the splash screen and logging the boot session, and /bin/plymouth which is the interface to /sbin/plymouthd. Unfortunately no man page is supplied for /bin/plymouth but there is some information in the /usr/share/doc/plymouth-0.7.0 subdirectory. Both have a number of useful options.

$ /sbin/plymouthd --help
Boot splash control server
USAGE: plymouthd [OPTION...]
  --help                 This help message
  --attach-to-session    Redirect console messages from screen to log
  --no-daemon            Do not daemonize
  --debug                Output debugging information
  --mode=        Mode is one of: boot, shutdown

$ /bin/plymouth --help
Boot splash control client
USAGE: plymouth [OPTION...] [COMMAND [OPTION...]...]

  --help                         This help message
  --debug                        Enable verbose debug logging
  --newroot=             Tell boot daemon that new root filesystem is mounted
  --quit                         Tell boot daemon to quit
  --ping                         Check of boot daemon is running
  --sysinit                      Tell boot daemon root filesystem is mounted read-write
  --show-splash                  Show splash screen
  --hide-splash                  Hide splash screen
  --ask-for-password             Ask user for password
  --ignore-keystroke=    Remove sensitivity to a keystroke
  --update=              Tell boot daemon an update about boot progress
  --details                      Tell boot daemon there were errors during boot
  --wait                         Wait for boot daemon to quit

Available commands:
  ask-for-password   Ask user for password
  ask-question       Ask user a question
  message            Display a message
  watch-keystroke    Become sensitive to a keystroke
  pause-progress     Pause boot progress bar
  unpause-progress   Unpause boot progress bar
  report-error       Tell boot daemon there were errors during boot
  quit               Tell boot daemon to quit

Options for ask-for-password command:
  --command=             Command to send password to via standard input
  --prompt=              Message to display when asking for password
  --number-of-tries=    Number of times to ask before giving up (requires --command)
  --dont-pause-progress          Don't pause boot progress bar while asking

Options for ask-question command:
  --command=       Command to send the answer to via standard input
  --prompt=        Message to display when asking the question
  --dont-pause-progress    Don't pause boot progress bar while asking

Options for message command:
  --text=    The message text

Options for watch-keystroke command:
  --command=    Command to send keystroke to via standard input
  --keys=       Keys to become sensitive to

Options for quit command:
  --retain-splash    Don't explicitly hide boot splash on exit

In Fedora /usr/bin/rhgb-client is a symbolic link to /usr/bin/plymouth

One way to experiment with Plymouth is to invoke it from runlevel 2 or 3. For example, here is a simple script to display the default theme for 5 seconds, ask for a password, and ask for your name before finally quitting.


# first check that we are in an appropriate runlevel
rlevel=$(runlevel | cut -d " " -f 2)
if [[ "$rlevel" != "2"  && "$rlevel" != "3" ]]
    echo "ERROR: You must be at runlevel 2 or 3"
    exit 1

echo "Testing plymouth default theme ..."
sleep 1

# check if the plymouthd daemon is alive
plymouth --ping
if [[ $? -eq 1 ]]
    echo "ERROR: Plymouth daemon not running"
    exit 1

# show the default splash screen for 5 seconds
plymouth  --show-splash
sleep 5

plymouth --ask-for-password
sleep 2

# using a command rather than an option
plymouth ask-question --prompt="What is your name?"
sleep 5

plymouth --quit

echo "Done ..."
exit 0

Note that not all plugins support every command and option at the present time. The above script works with the solar theme which uses the space-flares plugin. However this plugin does not support the message command for example. A useful option which is missing from plymouth would be an option to enumerate which commands were supported.

Plymouth is not really designed to be built from source by end users. For it to work correctly, it has to be integrated into the underlying distribution. Because it starts so early in the boot process, it needs to be added to a distribution’s initrd (initial ram disk) and the distribution needs to interface with plymouthd to tell it how the boot is progressing. Furthermore the initramfs has to include all the necessary files needed by an X server. For example, here is the nash script in my Fedora 11 initrd. Notice how the Plymouth splash screen is called as soon as a console is available and also several other times in the script.

lsinitrd /boot/initrd-
mount -t proc /proc /proc
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/fb c 29 0
mknod /dev/hvc0 c 229 0
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
daemonize --ignore-missing /bin/plymouthd
/lib/udev/console_init tty0
plymouth --show-splash
echo Setting up hotplug.
echo Creating block device nodes.
echo Creating character device nodes.
echo Making device-mapper control node
modprobe scsi_wait_scan
rmmod scsi_wait_scan
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure  vg_ultra
resume /dev/mapper/vg_ultra-lv_swap
echo Creating root device.
mkrootdev -t ext4 -o defaults,ro /dev/mapper/vg_ultra-lv_root
echo Mounting root filesystem.
mount /sysroot
cond -ne 0 plymouth --hide-splash
echo Setting up other filesystems.
plymouth --newroot=/sysroot
echo Switching to new root and running init.
echo Booting has failed.
sleep -1

During the boot progress the boot status is regularly updated with strings signifying what is happening. Plugins can listen to these if they choose to but they are generally ignored in the current plugins, and are only used for calculating the boot time estimation. In Fedora 11, For example the rc.sysinit script includes several calls to plymouth to hide or show the splash screen according to whether a password is needed to access a filesystem or a filesystem is to be relabeled by selinux.

So how does Plymouth know when to quit? Actually, it has no way of knowing. It just keeps on going until it receives a quit message. In the case of Fedora 11, the /etc/event.d/quit-plymouth script sends the quit message.

# quit-plymouth - script to stop boot splash
# This service triggers plymouth to quit when we reach the
# end of the boot cycle. We start on 'stopping rcX' to make sure
# this completes before the getty starts.
# prefdm handles quit differently, though.

start on runlevel S
start on stopping rc2
start on stopping rc3
start on stopping rc4

         /usr/bin/plymouth quit || :
end script

A special case is when a user boots to single user. In this case the /etc/event.d/rcS-sulogin script is executed.

# rcS-sulogin - "single-user" runlevel compatibility
# This task runs /bin/bash during "single-user" mode,
# then continues to the default runlevel.

start on runlevel S

stop on runlevel

console owner
        runlevel --set S >/dev/null || true
        plymouth --hide-splash || true
        exec /bin/bash
end script
post-stop script
        if [ "$1" = "S" ]; then
                runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab)
                [ -z "$runlevel" ] && runlevel="3"
                exec telinit $runlevel
end script

What is not commonly known is that you can also use Plymouth to provide a splash screen during system shutdown or reboot. This is done in Fedora 11 via the /etc/event.d/plymouth-shutdown script. as shown below.

# plymouth-shutdown - put up shutdown splash
# This service triggers plymouth to put up a splash
# when leaving runlevel 5.

start on stopped prefdm

console output
        set $(runlevel || true)
        if [ "$2" != "0" ] && [ "$2" != "6" ]; then
                exit 0

        /sbin/plymouthd --mode=shutdown || exit 1
        /bin/plymouth --sysinit
        /bin/plymouth --show-splash
        if [ "$2" = "0" ]; then
                /bin/plymouth message --text="Shutting down..."
        elif [ "$2" = "6" ]; then
                /bin/plymouth message --text="Restarting..."
end script

Console boot messages are redirected to a pseudo-terminal which is created very early on in the boot process. These messages are buffered until filesystems are fully mounted. Then the buffer is dumped to /var/log/boot.. In either text or graphics mode, the boot messages are obscured. However you can see these messages at any time during boot sequence by hitting the ESC key.

One of the side effects of changing Plymouth themes is that you have to generate a new initrd image. Usually this is done using the mkinird script. However there is an alternative to doing this. You can modify your existing initrd image to remove any Plymouth-related files and create a second initrd image which contains just the Plymouth-related files. When you change a theme, only the Plymouth image needs to be generated. You have to modify grub.conf to load both images when booting. Here is a stanza from my grub.conf which does just that.

title Graphical Boot (Fedora
        root (hd0,1)
        kernel /vmlinuz- ro root=/dev/mapper/vg_ultra-lv_root rhgb quiet nopat vga=0x37b 2
        initrd /initrd-  /initrd-plymouth.img

Here is a shell script which will generate the two images. It is based on existing scripts in the Plymouth codebase.

#  FPMurphy  9/12/2009

[ -z "$TMPDIR" ] && TMPDIR="/var/tmp"

[ -z "$LIBEXECDIR" ] && LIBEXECDIR="/usr/libexec"
[ -z "$DATADIR" ] && DATADIR="/usr/share"
[ -z "$PLYMOUTH_PLUGIN_PATH" ] && PLYMOUTH_PLUGIN_PATH="$(plymouth --get-splash-plugin-path)"
[ -z "$PLYMOUTH_LOGO_FILE" ] && PLYMOUTH_LOGO_FILE="/usr/share/plymouth/bizcom.png"
[ -z "$PLYMOUTH_THEME_NAME" ] && PLYMOUTH_THEME_NAME=$(plymouth-set-default-theme)

[ -z "$PLYMOUTH_IMAGE_FILE" ] && PLYMOUTH_IMAGE_FILE="/boot/initrd-plymouth.img"
[ -z "$IMAGE_FILE" ] && IMAGE_FILE="/boot/initrd-$(uname -r).img"

    if [ -f "${LIBEXECDIR}/initrd-functions" ]; then
    if [ -f "${DATADIR}/dracut/dracut-functions" ]; then


if [ " $(type -t inst) " != " function " ]; then
    echo "Need 'inst' function, try setting PLYMOUTH_POPULATE_SOURCE_FUNCTIONS to a file that defines it" 1>&2
    exit 1

if [ " $(type -t set_verbose) " != " function " ]; then
    function set_verbose { true; }

Function usage() {
    local output="/dev/stdout"
    local rc=0
    if [ "$1" == "error" ]; then

    echo "usage: plymouth_setup_initrds [ --verbose | -v ]" > $output
    exit $rc

while [ $# -gt 0 ]; do
    case $1 in
            usage normal
            usage error
set_verbose $verbose || :

INITRDDIR=`mktemp -d ${TMPDIR}/initrd.XXXXXX`
[ -z "$INITRDDIR" ] && {
     echo "mktemp failed"
     exit 1

mkdir -p ${INITRDDIR}${DATADIR}/plymouth/themes
inst /sbin/plymouthd $INITRDDIR /bin/plymouthd
inst /bin/plymouth $INITRDDIR
inst ${DATADIR}/plymouth/themes/text/text.plymouth $INITRDDIR
inst ${DATADIR}/plymouth/themes/details/details.plymouth $INITRDDIR
inst /etc/system-release $INITRDDIR
if [ -z "$PLYMOUTH_THEME_NAME" ]; then
    echo "No default plymouth plugin is set" > /dev/stderr
    exit 1

PLYMOUTH_MODULE_NAME=$(grep "ModuleName *= *" ${DATADIR}/plymouth/themes/${PLYMOUTH_THEME_NAME}/${PLYMOUTH_THEME_NAME}.plymouth | sed 's/ModuleName *= *//')

    echo "The default plymouth plugin (${PLYMOUTH_MODULE_NAME}) doesn't exist" > /dev/stderr
    exit 1


if [ -d ${DATADIR}/plymouth/themes/${PLYMOUTH_THEME_NAME} ]; then
    for x in ${DATADIR}/plymouth/themes/${PLYMOUTH_THEME_NAME}/* ; do
        [ ! -f "$x" ] && break
        inst $x $INITRDDIR

if [ -L ${DATADIR}/plymouth/themes/default.plymouth ]; then
    cp -a ${DATADIR}/plymouth/themes/default.plymouth $INITRDDIR${DATADIR}/plymouth/themes

# generate the initrd-plymouth image
if [ -f ${PLYMOUTH_IMAGE_FILE} ]; then

echo "Generating image: $PLYMOUTH_IMAGE_FILE"
rm -f lib*/{ld*,libc*,libdl*,libm*,libz*,libpthread*,libpng*,librt*}
rm -f usr/lib*/libpng*
find . | cpio -H newc --quiet -o | gzip -9 > ${PLYMOUTH_IMAGE_FILE}

rm -rf ${INITRDDIR}

#  now remove all plymouth items from regular initrd
INITRDDIR=`mktemp -d ${TMPDIR}/initrd.XXXXXX`
[ -z "$INITRDDIR" ] && {
     echo "mktemp failed"
     exit 1
zcat ${IMAGE_FILE} | cpio -i

rm -f ${INITRDDIR}/bin/plymout*
rm -f ${INITRDDIR}/lib64/libply*
rm -f ${INITRDDIR}/usr/lib64/libply*
rm -rf ${INITRDDIR}/usr/lib64/plymouth
rm -rf ${INITRDDIR}/usr/share/plymouth

echo "Generating image: ${IMAGE_FILE}"
findall . | cpio -H newc --quiet -o  | gzip -9 > ${IMAGE_FILE}

rm -rf ${INITRDDIR}

exit 0

Here is a listing of the generated /boot/initrd-plymouth.img image.

$ lsinitrd /boot/initrd-plymouth.img
drwx------   6 root     root            0 Sep 12 16:43 .
drwxr-xr-x   2 root     root            0 Sep 12 16:43 etc
-rw-r--r--   1 root     root           29 May 11 18:45 etc/fedora-release
lrwxrwxrwx   1 root     root           14 Sep 12 16:43 etc/system-release -> fedora-release
drwxr-xr-x   4 root     root            0 Sep 12 16:43 usr
drwxr-xr-x   3 root     root            0 Sep 12 16:43 usr/lib64
drwxr-xr-x   2 root     root            0 Sep 12 16:43 usr/lib64/plymouth
-rwxr-xr-x   1 root     root        27242 Sep 12 01:42 usr/lib64/plymouth/
-rwxr-xr-x   1 root     root        28471 Sep 12 01:42 usr/lib64/plymouth/
-rwxr-xr-x   1 root     root        80032 Sep 12 01:42 usr/lib64/plymouth/
-rwxr-xr-x   1 root     root       200218 Sep 12 01:42 usr/lib64/
lrwxrwxrwx   1 root     root           25 Sep 12 16:43 usr/lib64/ ->
drwxr-xr-x   3 root     root            0 Sep 12 16:43 usr/share
drwxr-xr-x   3 root     root            0 Sep 12 16:43 usr/share/plymouth
-rw-r--r--   1 root     root         5529 Sep 12 01:42 usr/share/plymouth/bizcom.png
drwxr-xr-x   5 root     root            0 Sep 12 16:43 usr/share/plymouth/themes
drwxr-xr-x   2 root     root            0 Sep 12 16:43 usr/share/plymouth/themes/details
-rw-r--r--   1 root     root           84 Sep 12 01:42 usr/share/plymouth/themes/details/details.plymouth
drwxr-xr-x   2 root     root            0 Sep 12 16:43 usr/share/plymouth/themes/text
-rw-r--r--   1 root     root           98 Sep 12 01:42 usr/share/plymouth/themes/text/text.plymouth
lrwxrwxrwx   1 root     root           20 Sep 12 16:43 usr/share/plymouth/themes/default.plymouth -> solar/solar.plymouth
drwxr-xr-x   2 root     root            0 Sep 12 16:43 usr/share/plymouth/themes/solar
-rw-r--r--   1 root     root          246 Sep 12 01:42 usr/share/plymouth/themes/solar/progress_bar.png
-rw-r--r--   1 root     root       355666 Sep 12 01:42 usr/share/plymouth/themes/solar/star.png
-rw-r--r--   1 root     root         1896 Sep 12 01:42 usr/share/plymouth/themes/solar/lock.png
-rw-r--r--   1 root     root          165 Sep 12 01:42 usr/share/plymouth/themes/solar/solar.plymouth
-rw-r--r--   1 root     root          296 Sep 12 01:42 usr/share/plymouth/themes/solar/bullet.png
-rw-r--r--   1 root     root          870 Sep 12 01:42 usr/share/plymouth/themes/solar/box.png
-rw-r--r--   1 root     root          350 Sep 12 01:42 usr/share/plymouth/themes/solar/entry.png
drwxr-xr-x   2 root     root            0 Sep 12 16:43 lib64
-rwxr-xr-x   1 root     root       293522 Sep 12 01:42 lib64/
lrwxrwxrwx   1 root     root           15 Sep 12 16:43 lib64/ ->
drwxr-xr-x   2 root     root            0 Sep 12 16:43 bin
-rwxr-xr-x   1 root     root        70256 Sep 12 01:42 bin/plymouth
-rwxr-xr-x   1 root     root       110319 Sep 12 01:42 bin/plymouthd

As you can see it only contains Plymouth-related files. It does not contain the label plugin because this is loaded in using dlopen() when needed.

You can debug Plymouth by adding plymouth:debug, plymouth:debug=file:, or plymouth:debug=file:path_to_log_file on the kernel command line. The default file is /var/log/plymouth-debug.log if logging to a file is specified but no file is specified, i.e. option two. Other kernel command line options include console=/dev/what_ever_works to override the default console (/dev/tty0) and plymouth:splash=name_of_theme to override the default theme.

There are also a number of key combinations such as CTRL-L to redraw the screen, CTRL-V to toggle debug mode and CTRL-T to enable text mode. Unfortunately I was unable to get any of these key combinations to work. However the ESC key worked as expected and toggled the display between detailed and the default theme.

Plymouth does all pixel manipulation in software. There is no GPU acceleration. It does not use MMX (Matrix Math Extension) or SSE (Streaming SIMD Extension) hence there is no CPU acceleration either. A plugin that loads a lot of images or does a lot of full screen updates will be slower than one that loads a few images and just updates small parts of the screen. Much of what has been written about Plymouth in the computing press implies that the goal of Plymouth is to provide a faster boot up experience but that is not an explicit design goal of Plymouth.

Well that is about all the useful information on Plymouth that I have time to write about at present. After reading this post, I hope you have a better understanding of Plymouth and how it relates to the boot sequence. Remember however that this project is in active development. and nothing is cast in stone. For example, the inclusion of Dracut, a replacement for nash, in Fedora 12 (Constantine) may affect how Plymouth is invoked. Themes and plug-ins are also rapidly evolving.

As Plymouth is implemented in other GNU/Linux distributions such as Ubuntu, expect to see a flourishing of graphical boot themes from independent authors. I look forward to that day.

2 comments to Project Plymouth

  • Simon B.

    “The key idea behind Plymouth is to start the X server very early on
    the boot process and to continue using that X server during login and
    user sessions.”
    That passage sounds more like Chrome OS than plymouth.

    Mailing list archives also mention that even though Brie hosts two plugins, doesn’t mean he himself developed them. My wild guess is that several people were involved.

  • You are right about that sentence! I have modified it.

    Nope, as far as I can tell, all credit should go to Charlie Brej for these two plugins.