Plymouth is the codename for a freedesktop.org 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
| COLORS | 640x480 | 800x600 | 1024x768 | 1280x1024 | 1600x1200 |
|---|---|---|---|---|---|
| 256 | 0301 | 0303 | 0305 | 0307 | 031C |
| 32768 | 0310 | 0313 | 0316 | 0319 | 031D |
| 65536 | 0311 | 0314 | 0317 | 031A | 031E |
| 16.8M | 0312 | 0315 | 0318 | 031B | 031F |
and here is the same table using decimal numbers.
| COLORS | 640x480 | 800x600 | 1024x768 | 1280x1024 | 1600x1200 |
|---|---|---|---|---|---|
| 256 | 769 | 771 | 773 | 775 | 796 |
| 32768 | 784 | 787 | 790 | 793 | 797 |
| 65536 | 785 | 788 | 791 | 794 | 798 |
| 16.8M | 786 | 789 | 792 | 795 | 799 |
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 charge details fade-in spinfinity text
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] Name=Charge Description=A theme that features the shadowy hull of a Fedora logo charge up and and finally burst into into full form. ModuleName=two-step [two-step] ImageDir=/usr/share/plymouth/themes/charge HorizontalAlignment=.5 VerticalAlignment=.5 Transition=none TransitionDuration=0.0 BackgroundStartColor=0x416fa7 BackgroundEndColor=0x4b83c1
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...] Options: --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...]...] Options: --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.
#!/bin/sh
# first check that we are in an appropriate runlevel
rlevel=$(runlevel | cut -d " " -f 2)
if [[ "$rlevel" != "2" && "$rlevel" != "3" ]]
then
echo "ERROR: You must be at runlevel 2 or 3"
exit 1
fi
echo "Testing plymouth default theme ..."
plymouthd
sleep 1
# check if the plymouthd daemon is alive
plymouth --ping
if [[ $? -eq 1 ]]
then
echo "ERROR: Plymouth daemon not running"
exit 1
fi
# 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-2.6.29.5-191.fc11.x86_64.img ......................... #!/bin/nash mount -t proc /proc /proc setquiet 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. hotplug echo Creating block device nodes. mkblkdevs echo Creating character device nodes. mkchardevs echo Making device-mapper control node mkdmnod modprobe scsi_wait_scan rmmod scsi_wait_scan mkblkdevs 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. setuproot loadpolicy plymouth --newroot=/sysroot echo Switching to new root and running init. switchroot echo Booting has failed. sleep -1 init
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
script
/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
script
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
fi
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
script
set $(runlevel || true)
if [ "$2" != "0" ] && [ "$2" != "6" ]; then
exit 0
fi
/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..."
fi
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 2.6.29.6-217.2.16.fc11.x86_64)
root (hd0,1)
kernel /vmlinuz-2.6.30.5-43.fc11.x86_64 ro root=/dev/mapper/vg_ultra-lv_root rhgb quiet nopat vga=0x37b 2
initrd /initrd-2.6.30.5-43.fc11.x86_64.img /initrd-plymouth.img
Here is a shell script which will generate the two images. It is based on existing scripts in the Plymouth codebase.
#!/bin/bash
#
#
# 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 [ -z "$PLYMOUTH_POPULATE_SOURCE_FUNCTIONS" ]; then
if [ -f "${LIBEXECDIR}/initrd-functions" ]; then
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS="${LIBEXECDIR}/initrd-functions"
fi
if [ -f "${DATADIR}/dracut/dracut-functions" ]; then
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS="${DATADIR}/dracut/dracut-functions"
fi
fi
if [ -n "$PLYMOUTH_POPULATE_SOURCE_FUNCTIONS" ]; then
source $PLYMOUTH_POPULATE_SOURCE_FUNCTIONS
fi
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
fi
if [ " $(type -t set_verbose) " != " function " ]; then
function set_verbose { true; }
fi
Function usage() {
local output="/dev/stdout"
local rc=0
if [ "$1" == "error" ]; then
output="/dev/stderr"
rc=1
fi
echo "usage: plymouth_setup_initrds [ --verbose | -v ]" > $output
exit $rc
}
verbose=false
INITRDDIR=""
while [ $# -gt 0 ]; do
case $1 in
--verbose|-v)
verbose=true
;;
--help|-h)
usage normal
;;
*)
usage error
break
;;
esac
shift
done
set_verbose $verbose || :
CURRENTDIR=`pwd`
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 ${PLYMOUTH_PLUGIN_PATH}/text.so $INITRDDIR
inst ${DATADIR}/plymouth/themes/details/details.plymouth $INITRDDIR
inst ${PLYMOUTH_PLUGIN_PATH}/details.so $INITRDDIR
inst ${PLYMOUTH_LOGO_FILE} $INITRDDIR
inst /etc/system-release $INITRDDIR
if [ -z "$PLYMOUTH_THEME_NAME" ]; then
echo "No default plymouth plugin is set" > /dev/stderr
exit 1
fi
PLYMOUTH_MODULE_NAME=$(grep "ModuleName *= *" ${DATADIR}/plymouth/themes/${PLYMOUTH_THEME_NAME}/${PLYMOUTH_THEME_NAME}.plymouth | sed 's/ModuleName *= *//')
if [ ! -f ${PLYMOUTH_PLUGIN_PATH}/${PLYMOUTH_MODULE_NAME}.so ]; then
echo "The default plymouth plugin (${PLYMOUTH_MODULE_NAME}) doesn't exist" > /dev/stderr
exit 1
fi
inst ${PLYMOUTH_PLUGIN_PATH}/${PLYMOUTH_MODULE_NAME}.so $INITRDDIR
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
done
fi
if [ -L ${DATADIR}/plymouth/themes/default.plymouth ]; then
cp -a ${DATADIR}/plymouth/themes/default.plymouth $INITRDDIR${DATADIR}/plymouth/themes
fi
# generate the initrd-plymouth image
if [ -f ${PLYMOUTH_IMAGE_FILE} ]; then
mv ${PLYMOUTH_IMAGE_FILE} ${PLYMOUTH_IMAGE_FILE}.bak
fi
echo "Generating image: $PLYMOUTH_IMAGE_FILE"
cd ${INITRDDIR}
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}
cd ${CURRENTDIR}
rm -rf ${INITRDDIR}
# now remove all plymouth items from regular initrd
INITRDDIR=`mktemp -d ${TMPDIR}/initrd.XXXXXX`
[ -z "$INITRDDIR" ] && {
echo "mktemp failed"
exit 1
}
cd ${INITRDDIR}
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}"
mv ${IMAGE_FILE} ${IMAGE_FILE}.bak
findall . | cpio -H newc --quiet -o | gzip -9 > ${IMAGE_FILE}
cd ${CURRENTDIR}
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/details.so -rwxr-xr-x 1 root root 28471 Sep 12 01:42 usr/lib64/plymouth/text.so -rwxr-xr-x 1 root root 80032 Sep 12 01:42 usr/lib64/plymouth/space-flares.so -rwxr-xr-x 1 root root 200218 Sep 12 01:42 usr/lib64/libplybootsplash.so.2.0.0 lrwxrwxrwx 1 root root 25 Sep 12 16:43 usr/lib64/libplybootsplash.so.2 -> libplybootsplash.so.2.0.0 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/libply.so.2.0.0 lrwxrwxrwx 1 root root 15 Sep 12 16:43 lib64/libply.so.2 -> libply.so.2.0.0 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.
“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 http://lists.freedesktop.org/archives/plymouth/2009-December/thread.html 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.