Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Project Plymouth

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.

Plymouth is designed to work on systems with DRM (Direct Rendering Manager) kernel modesetting 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. The idea behind Plymouth is that very early on in the boot process the 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. 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. Currently, 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, was not included in Fedora 11. 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 Brie, 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. 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.
 

Linux HPET Support

IA-PC HPET (High Precision Event Timer) is a specification which was jointly developed by Intel and Microsoft in the early part of this decade.. The latest version is dated October 2004. It's stated purpose is to
initially supplement and eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs.


The HPET architecture defines a set of timers that can be used by the operating system. A timer block is a combination of a single counter and up to 32 comparators and match registers. The comparator compares the contents of the match register against the value of a free running monotonic up-counter. When the output of the up-counter equals the value in the match register an interrupt is generated. Each of the comparators can output an interrupt. A maximum of 8 timer blocks are supported for a total of 256 timers. Each timer block can have different clocking attributes. Specific implementations may include only a subset of these timers. A minimum of three timers is required.

The specification contains the following block diagram of the HPET architecture.

Hardware Block Diagram

Some of the timers may be enabled to generate a periodic interrupt. If a timer is set to be periodic, its period is added to the match register each time a match occurs, thus computing the next time for this timer to generate an interrupt.. An up-counter is usually 64 bits wide but 32-bit implementations are permitted by the specification and 64-bit up-counters can also be driven in 32-bit mode. Up-counters run at a minimum of 10 MHz. which is much faster than the older RTC (Real Time Clock) and can thus produce periodic interrupts at a much higher resolution. The registers associated with these timers are mapped to memory space.

The BIOS uses ACPI ( Advanced Configuration and Power Interface) functionality to inform the operating system of the location of the HPET memory-mapped register space. Here is an example of a disassembled ACPI HPET table from an Intel DX48BT2 (AKA BoneTrail) motherboard.

$ cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
$ iasl -d /var/tmp/hpet.out
$ cat /var/tmp/hpet.dsl
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090123
*
* Disassembly of /var/tmp/hpet.out, Sun Jul 5 19:34:47 2009
*
* ACPI Data Table [HPET]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/

[000h 000 4] Signature : "HPET" /* High Precision Event Timer table */
[004h 004 4] Table Length : 00000038
[008h 008 1] Revision : 01
[009h 009 1] Checksum : CE
[00Ah 010 6] Oem ID : "INTEL "
[010h 016 8] Oem Table ID : "DX48BT2 "
[018h 024 4] Oem Revision : 0000076E
[01Ch 028 4] Asl Compiler ID : "MSFT"
[020h 032 4] Asl Compiler Revision : 01000013

[024h 036 4] Hardware Block ID : 8086A301

[028h 040 12] Timer Block Register :
[028h 040 1] Space ID : 00 (SystemMemory)
[029h 041 1] Bit Width : 00
[02Ah 042 1] Bit Offset : 00
[02Bh 043 1] Access Width : 00
[02Ch 044 8] Address : 00000000FED00000

[034h 052 1] Sequence Number : 00
[035h 053 2] Minimum Clock Ticks : 0001
[037h 055 1] Flags (decoded below) : 00
Page Protect : 0
4K Page Protect : 0
64K Page Protect : 0
Raw Table Data

0000: 48 50 45 54 38 00 00 00 01 CE 49 4E 54 45 4C 20 HPET8.....INTEL
0010: 44 58 34 38 42 54 32 20 6E 07 00 00 4D 53 46 54 DX48BT2 n...MSFT
0020: 13 00 00 01 01 A3 86 80 00 00 00 00 00 00 D0 FE ................
0030: 00 00 00 00 00 01 00 00 ........
$

See page 30 of the HPET v1.0a specification for a detailed breakdown of the individual bits in the Event Time Block (called Hardware Block by the AML disassember). Note that only one Event Timer Block need be described in the HPET table in order to bootstrap an operating system. This is the case here. For non-legacy platforms, the Event Timer Block described in the HPET is the one that provides functionality to replace the 8254/RTC Periodic Interrupt Logic.

Other Event Time Blocks are described in the ACPI namespace. Here is the relevant section from the disassembled ACPI DSDT table.

Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00004000, // Address Length
)
})
Method (_STA, 0, NotSerialized)
{
If (HPEE)
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}
}

Note the assigned PNPID (PNP0103) for the HPET. Because no _UID is specified it means that there are no other HPET timer blocks.

Here is a list of the HPET-related messages outputted when this particular motherboard is booted up under Fedora 11.

$ dmesg | grep -i HPET
ACPI: HPET CFBF2000, 0038 (r1 INTEL DX48BT2 76E MSFT 1000013)
ACPI: HPET id: 0x8086a301 base: 0xfed00000
hpet clockevent registered
HPET: 4 timers in total, 0 timers will be used for per-cpu timer
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 comparators, 64-bit 14.318180 MHz counter
rtc0: alarms up to one month, 114 bytes nvram, hpet irqs
$

The first line is outputted when the ACPI HPET table is read. The second line is outputted when the ACPI HPET table is mapped into memory by .../arch/x86/kernel/acpi/boot.c. The next line is outputted when the HPET legacy interrupts are started and HPET is registered as the global clock. The following line is outputted when the kernel checks to ensure that at least one timer is reserved for userspace (/dev/hpet.) The next two lines of output comes from the HPET device driver (.../drivers/char/hpet.c.) It shows that 2 timers have allocated interrupts and two do not..

Here is the relevant part of the output from /proc/time_list as it relates to HPET:

Tick Device: mode: 1
Broadcast device
Clock Event Device: hpet
max_delta_ns: 149983005959
min_delta_ns: 5000
mult: 61496114
shift: 32
mode: 3
next_event: 9223372036854775807 nsecs
set_next_event: hpet_legacy_next_event
set_mode: hpet_legacy_set_mode
event_handler: tick_handle_oneshot_broadcast
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000

Here is the output from /proc/sys/dev/hpet and /proc/driver/rtc:

$ cat /proc/sys/dev/hpet/max-user-freq
64
$ cat /proc/driver/rtc
rtc_time : 06:34:31
rtc_date : 2009-07-06
alrm_time : **:24:40
alrm_date : ****-**-**
alarm_IRQ : no
alrm_pending : no
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay


The HPET driver (/dev/hpet) has a similar API to the Real Time Clock driver. It is a character device which can support any number of HPET devices. The kernel API has three interfaces exported from the driver:

hpet_register( struct hpet_task *tp, int periodic )
hpet_unregister( struct hpet_task *tp )
hpet_control( struct hpet_task *tp, unsigned int cmd, unsigned long arg )

The userspace interface to HPET is defined in the header /usr/include/linux/hpet.h. The current set of supported operations is:

#define HPET_IE_ON _IO('h', 0x01) /* interrupt on */
#define HPET_IE_OFF _IO('h', 0x02) /* interrupt off */
#define HPET_INFO _IOR('h', 0x03, struct hpet_info) /* get information */
#define HPET_EPI _IO('h', 0x04) /* enable periodic */
#define HPET_DPI _IO('h', 0x05) /* disable periodic */
#define HPET_IRQFREQ _IOW('h', 0x6, unsigned long) /* set frequency */

The following example shows how to use the published interface to access a HPET and call a simple periodic signal handler hpet_alarm between 2 and 99 times a second.
#include <stdio.h>
#include <stdlib.h;>
#include <fcntl.h>
#include <time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/time.h>
#include <linux/hpet.h>
#include <stdint.h>
#include <sys/ioctl.h>
#include <signal.h>

static uint16_t hpet_sigio_count;
static uint64_t secs;

static void
hpet_alarm(int val)
{
struct timespec t;
clock_gettime(CLOCK_REALTIME, &t);

if (!secs) secs = t.tv_sec;

fprintf(stderr, "hpet_alarm called. iteration: %2d secs: %ld nsecs: %ld \n",
hpet_sigio_count, (t.tv_sec - secs) , t.tv_sec * 100000 + t.tv_nsec );

hpet_sigio_count++;
}

int
main(int argc, const char **argv)
{
struct sigaction old, new;
struct hpet_info info;
int frequency;
int iterations;
int retval = 0;
int fd;
int r, i, value;

if (argc != 3) {
fprintf(stderr, "Usage: %s frequency(1-64) iterations(10-99)\n", argv[0]);
return -1;
}

frequency = atoi(argv[1]);
iterations = atoi(argv[2]);

if (frequency > 64 || frequency < 1 ) {
fprintf(stderr, "ERROR: Invalid value for frequency\n");
return -1;
}

if (iterations < 10 || iterations > 99 ) {
fprintf(stderr, "ERROR: Invalid value for iterations\n");
return -1;
}

hpet_sigio_count = 0;

sigemptyset(&new.sa_mask);
new.sa_flags = 0;
new.sa_handler = hpet_alarm;

sigaction(SIGIO, NULL, &old);
sigaction(SIGIO, &new, NULL);

fd = open("/dev/hpet", O_RDONLY);
if (fd < 0) {
fprintf(stderr, "ERROR: Failed to open /dev/hpet\n");
return -1;
}

if ((fcntl(fd, F_SETOWN, getpid()) == 1) ||
((value = fcntl(fd, F_GETFL)) == 1) ||
(fcntl(fd, F_SETFL, value | O_ASYNC) == 1)) {
fprintf(stderr, "ERROR: fcntl failed\n");
retval = 1;
goto fail;
}

if (ioctl(fd, HPET_IRQFREQ, frequency) < 0) {
fprintf(stderr, "ERROR: Could not set /dev/hpet to have a %2dHz timer\n", frequency);
retval = 2;
goto fail;
}

if (ioctl(fd, HPET_INFO, &info) < 0) {
fprintf(stderr, "ERROR: failed to get info\n");
retval = 3;
goto fail;
}

fprintf(stdout, "\nhi_ireqfreq: 0x%lx hi_flags: %0x%lx hi_hpet: 0x%x hi_timer: 0x%x\n\n",
info.hi_ireqfreq, info.hi_flags, info.hi_hpet, info.hi_timer);

r = ioctl(fd, HPET_EPI, 0);
if (info.hi_flags && (r < 0)) {
fprintf(stderr, "ERROR: HPET_EPI failed\n");
retval = 4;
goto fail;
}

if (ioctl(fd, HPET_IE_ON, 0) < 0) {
fprintf(stderr, "ERROR: HPET_IE_ON failed\n");
retval = 5;
goto fail;
}

/* wait for specified number of signal interrupts */
for (i = 0; i < iterations; i++) {
(void) pause();
}

if (ioctl(fd, HPET_IE_OFF, 0) < 0) {
fprintf(stderr, "ERROR: HPET_IE_OFF failed\n");
retval = 6;
}

fail:
sigaction(SIGIO, &old, NULL);

if (fd > 0)
close(fd);

return retval;
}

Here is the output from this example when it is invoked with a frequency of 32 and an iteration count of 64.

$ sudo ./hpet_example 32 64

hi_ireqfreq: 0x20 hi_flags: 00 hi_hpet: 0x2 hi_timer: 0x4a1cb9c8

hpet_alarm called. iteration: 0 secs: 0 nsecs: 124683205055050
hpet_alarm called. iteration: 1 secs: 0 nsecs: 124683236313149
hpet_alarm called. iteration: 2 secs: 0 nsecs: 124683267566342
hpet_alarm called. iteration: 3 secs: 0 nsecs: 124683298821905
hpet_alarm called. iteration: 4 secs: 0 nsecs: 124683330077493
hpet_alarm called. iteration: 5 secs: 0 nsecs: 124683361341893
hpet_alarm called. iteration: 6 secs: 0 nsecs: 124683392590764
hpet_alarm called. iteration: 7 secs: 0 nsecs: 124683423849157
hpet_alarm called. iteration: 8 secs: 0 nsecs: 124683455101917
hpet_alarm called. iteration: 9 secs: 0 nsecs: 124683486357683
hpet_alarm called. iteration: 10 secs: 0 nsecs: 124683517617931
hpet_alarm called. iteration: 11 secs: 0 nsecs: 124683548872198
hpet_alarm called. iteration: 12 secs: 1 nsecs: 124682580229541
hpet_alarm called. iteration: 13 secs: 1 nsecs: 124682611481235
hpet_alarm called. iteration: 14 secs: 1 nsecs: 124682642740016
hpet_alarm called. iteration: 15 secs: 1 nsecs: 124682673992697
hpet_alarm called. iteration: 16 secs: 1 nsecs: 124682705247479
hpet_alarm called. iteration: 17 secs: 1 nsecs: 124682736504664
hpet_alarm called. iteration: 18 secs: 1 nsecs: 124682767758840
hpet_alarm called. iteration: 19 secs: 1 nsecs: 124682799014280
hpet_alarm called. iteration: 20 secs: 1 nsecs: 124682830270129
hpet_alarm called. iteration: 21 secs: 1 nsecs: 124682861530334
hpet_alarm called. iteration: 22 secs: 1 nsecs: 124682892784577
hpet_alarm called. iteration: 23 secs: 1 nsecs: 124682924038220
hpet_alarm called. iteration: 24 secs: 1 nsecs: 124682955294110
hpet_alarm called. iteration: 25 secs: 1 nsecs: 124682986550572
hpet_alarm called. iteration: 26 secs: 1 nsecs: 124683017805756
hpet_alarm called. iteration: 27 secs: 1 nsecs: 124683049061117
hpet_alarm called. iteration: 28 secs: 1 nsecs: 124683080318331
hpet_alarm called. iteration: 29 secs: 1 nsecs: 124683111576954
hpet_alarm called. iteration: 30 secs: 1 nsecs: 124683142828988
hpet_alarm called. iteration: 31 secs: 1 nsecs: 124683174083954
hpet_alarm called. iteration: 32 secs: 1 nsecs: 124683205337967
hpet_alarm called. iteration: 33 secs: 1 nsecs: 124683236593144
hpet_alarm called. iteration: 34 secs: 1 nsecs: 124683267851530
hpet_alarm called. iteration: 35 secs: 1 nsecs: 124683299104054
hpet_alarm called. iteration: 36 secs: 1 nsecs: 124683330358748
hpet_alarm called. iteration: 37 secs: 1 nsecs: 124683361617445
hpet_alarm called. iteration: 38 secs: 1 nsecs: 124683392870249
hpet_alarm called. iteration: 39 secs: 1 nsecs: 124683424124489
hpet_alarm called. iteration: 40 secs: 1 nsecs: 124683455379717
hpet_alarm called. iteration: 41 secs: 1 nsecs: 124683486634424
hpet_alarm called. iteration: 42 secs: 1 nsecs: 124683517889149
hpet_alarm called. iteration: 43 secs: 1 nsecs: 124683549144315
hpet_alarm called. iteration: 44 secs: 2 nsecs: 124682580500695
hpet_alarm called. iteration: 45 secs: 2 nsecs: 124682611761325
hpet_alarm called. iteration: 46 secs: 2 nsecs: 124682643011863
hpet_alarm called. iteration: 47 secs: 2 nsecs: 124682674265864
hpet_alarm called. iteration: 48 secs: 2 nsecs: 124682705521034
hpet_alarm called. iteration: 49 secs: 2 nsecs: 124682736776049
hpet_alarm called. iteration: 50 secs: 2 nsecs: 124682768030654
hpet_alarm called. iteration: 51 secs: 2 nsecs: 124682799285398
hpet_alarm called. iteration: 52 secs: 2 nsecs: 124682830544701
hpet_alarm called. iteration: 53 secs: 2 nsecs: 124682861797319
hpet_alarm called. iteration: 54 secs: 2 nsecs: 124682893051578
hpet_alarm called. iteration: 55 secs: 2 nsecs: 124682924306748
hpet_alarm called. iteration: 56 secs: 2 nsecs: 124682955562132
hpet_alarm called. iteration: 57 secs: 2 nsecs: 124682986823545
hpet_alarm called. iteration: 58 secs: 2 nsecs: 124683018073636
hpet_alarm called. iteration: 59 secs: 2 nsecs: 124683049327560
hpet_alarm called. iteration: 60 secs: 2 nsecs: 124683080586707
hpet_alarm called. iteration: 61 secs: 2 nsecs: 124683111841132
hpet_alarm called. iteration: 62 secs: 2 nsecs: 124683143095147
hpet_alarm called. iteration: 63 secs: 2 nsecs: 124683174349985
hpet_alarm called. iteration: 64 secs: 2 nsecs: 124683205607103
$

Well, I think that I have provided you with enough information so that you should now be able to go away and experiment with the HPET interface yourself.

By the way, not all VMware products support HPET. Currently ESX does not provide a virtual HPET to guest operating systems and in some cases it may be necessary to disable HPET altogether because of timer drift in virtual machines. See VMware TimeKeeping for more information.

P.S. I tested the the above example on an Intel DX48BT2 motherboard running a 2.6.29.5-191 kernel.
 

Fedora 11 nVidia Twinview Support

Fedora 11 (Leonidas) ships with the nouveau nVidia graphics driver preloaded by default if a nVidia graphics card is detected at install time.  Previous versions of Fedora used the older X.Org nv driver.

The nouveau project aims at producing Open Source 3D drivers for nVidia graphics cards.  According to the nouveau project Wiki

2D-support is in fairly good shape with EXA acceleration, Xv and Randr12 (think of dual-head, rotations, etc.). Randr12 should work for all cards up to, and including, Geforce 9000 series, although some issues with Geforce 8/9 laptops may still exist, for such issues bug reports should be submitted. Randr12 is now the default. Any 3D functionality that might exist is still unsupported, do not ask for instructions to try it. Also, VT switching while X is running is considered lucky."

Well, I certainly quickly ran into the VT switching issue!  It worked but not consistently.

Unfortunately the nouveau driver currently does not support nVidia TwinView functionality and I suspect that it will be a long time before it does if ever!

To use TwinView with Fedora 11, you have to load the correct nVidia drivers from rpmfusion.org.  I described how to do this in detail in a previous post so I will not repeat that information here.

You also need to modify your grub.conf file to include the nopat kernel boot option as shown below.
title Fedora (2.6.29.4-167.fc11.x86_64)
root (hd0,1)
kernel /vmlinuz-2.6.29.4-167.fc11.x86_64 ro root=/dev/mapper/vg_ultra-lv_root rhgb quiet nopat
initrd /initrd-2.6.29.4-167.fc11.x86_64.img
The nopat option is needed for this particular kernel (2.6.29.4) as it appears to still have broken PAT functionality.

For those readers who are unaware of what PAT is, here is a brief explanation.  Traditionally page caching was controlled by a CPU feature called Memory Type Range Registers (MTRR).  A CPU has a finite and limited set of MTRRs each of which control part of the physical address space.  To overcome this limitation and provide a more flexible architecture, Intel and other x86 CPU vendors added a set of bits to page table entries to control how a CPU does page caching.  These bits are called the Page Attribute Table (PAT).  Incidentally, the 2.6.26 kernel was the first Linux kernel to support PATs.

Unless you rebuild your initial ramdisk (initrd), the nouveau driver will remain loaded in the kernel.  I prefer not to have the nouveau driver loaded in my kernel if I am not using it so I added nouveau to the list of blacklisted drivers in /etc/modprobe.d/blacklist.conf and rebuild initrd.
# mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.backup
# mkinitrd -v /boot/initrd-`uname -r`.img `uname -r`
Creating initramfs
Looking for driver for /dev/mapper/vg_ultra-lv_root in /sys/block/dm-0
Found DeviceMapper component dm-0
Looking for deps of module scsi:t-0x00
Looking for deps of module pci:v00008086d00002922sv00008086sd00005442bc01sc06i01
Looking for driver for /dev/mapper/vg_ultra-lv_swap in /sys/block/dm-1
Found DeviceMapper component dm-1
Using modules:
Building initrd in /tmp/initrd.txR0Kd
/sbin/nash -> /tmp/initrd.txR0Kd/bin/nash
/usr/lib64/libnash.so.6.0.86 -> /tmp/initrd.txR0Kd/usr/lib64/libnash.so.6.0.86
/usr/lib64/libbdevid.so.6.0.86 -> /tmp/initrd.txR0Kd/usr/lib64/libbdevid.so.6.0.86
/lib64/libdevmapper.so.1.02 -> /tmp/initrd.txR0Kd/lib64/libdevmapper.so.1.02
/lib64/libparted-1.8.so.8 -> /tmp/initrd.txR0Kd/lib64/libparted-1.8.so.8
/lib64//libparted-1.8.so.8.0.0 -> /tmp/initrd.txR0Kd/lib64//libparted-1.8.so.8.0.0
/lib64/libblkid.so.1 -> /tmp/initrd.txR0Kd/lib64/libblkid.so.1
/lib64//libblkid.so.1.0 -> /tmp/initrd.txR0Kd/lib64//libblkid.so.1.0
/lib64/libselinux.so.1 -> /tmp/initrd.txR0Kd/lib64/libselinux.so.1
/lib64/libsepol.so.1 -> /tmp/initrd.txR0Kd/lib64/libsepol.so.1
/lib64/libuuid.so.1 -> /tmp/initrd.txR0Kd/lib64/libuuid.so.1
/lib64//libuuid.so.1.2 -> /tmp/initrd.txR0Kd/lib64//libuuid.so.1.2
/lib64/libpopt.so.0 -> /tmp/initrd.txR0Kd/lib64/libpopt.so.0
/lib64//libpopt.so.0.0.0 -> /tmp/initrd.txR0Kd/lib64//libpopt.so.0.0.0
/lib64/libresolv.so.2 -> /tmp/initrd.txR0Kd/lib64/libresolv.so.2
/lib64//libresolv-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//libresolv-2.10.1.so
/lib64/libc.so.6 -> /tmp/initrd.txR0Kd/lib64/libc.so.6
/lib64//libc-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//libc-2.10.1.so
/lib64/ld-linux-x86-64.so.2 -> /tmp/initrd.txR0Kd/lib64/ld-linux-x86-64.so.2
/lib64//ld-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//ld-2.10.1.so
/lib64/libdl.so.2 -> /tmp/initrd.txR0Kd/lib64/libdl.so.2
/lib64//libdl-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//libdl-2.10.1.so
/usr/lib64/libelf.so.1 -> /tmp/initrd.txR0Kd/usr/lib64/libelf.so.1
/usr/lib64//libelf-0.141.so -> /tmp/initrd.txR0Kd/usr/lib64//libelf-0.141.so
/usr/lib64/libnl.so.1 -> /tmp/initrd.txR0Kd/usr/lib64/libnl.so.1
/usr/lib64//libnl.so.1.1 -> /tmp/initrd.txR0Kd/usr/lib64//libnl.so.1.1
/lib64/libm.so.6 -> /tmp/initrd.txR0Kd/lib64/libm.so.6
/lib64//libm-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//libm-2.10.1.so
/lib64/libgcc_s.so.1 -> /tmp/initrd.txR0Kd/lib64/libgcc_s.so.1
/lib64//libgcc_s-4.4.0-20090506.so.1 -> /tmp/initrd.txR0Kd/lib64//libgcc_s-4.4.0-20090506.so.1
/lib64/libreadline.so.5 -> /tmp/initrd.txR0Kd/lib64/libreadline.so.5
/lib64//libreadline.so.5.2 -> /tmp/initrd.txR0Kd/lib64//libreadline.so.5.2
/lib64/librt.so.1 -> /tmp/initrd.txR0Kd/lib64/librt.so.1
/lib64//librt-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//librt-2.10.1.so
/lib64/libpthread.so.0 -> /tmp/initrd.txR0Kd/lib64/libpthread.so.0
/lib64//libpthread-2.10.1.so -> /tmp/initrd.txR0Kd/lib64//libpthread-2.10.1.so
/lib64/libtinfo.so.5 -> /tmp/initrd.txR0Kd/lib64/libtinfo.so.5
/lib64//libtinfo.so.5.7 -> /tmp/initrd.txR0Kd/lib64//libtinfo.so.5.7
/sbin/modprobe -> /tmp/initrd.txR0Kd/bin/modprobe
/sbin/rmmod -> /tmp/initrd.txR0Kd/bin/rmmod
resolving for MODULES
and that has items of
resolving for availmodules
and that has items of
/sbin/lvm -> /tmp/initrd.txR0Kd/bin/lvm
/etc/lvm -> /tmp/initrd.txR0Kd/etc/lvm
`/etc/lvm/lvm.conf' -> `/tmp/initrd.txR0Kd/etc/lvm/lvm.conf'
/etc/sysconfig/keyboard -> /tmp/initrd.txR0Kd/etc/sysconfig/keyboard
/bin/loadkeys -> /tmp/initrd.txR0Kd/bin/loadkeys
/lib/kbd/keymaps/i386/qwerty/us.map.gz -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/qwerty/us.map.gz
/lib/kbd/keymaps/i386/include/qwerty-layout.inc -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/include/qwerty-layout.inc
/lib/kbd/keymaps/i386/include/compose.inc -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/include/compose.inc
/lib/kbd/keymaps/include/compose.latin4 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.latin4
/lib/kbd/keymaps/include/compose.8859_8 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.8859_8
/lib/kbd/keymaps/include/compose.latin1 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.latin1
/lib/kbd/keymaps/include/compose.latin3 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.latin3
/lib/kbd/keymaps/include/compose.8859_7 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.8859_7
/lib/kbd/keymaps/include/compose.latin2 -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.latin2
/lib/kbd/keymaps/include/compose.latin -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/include/compose.latin
/lib/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc
/lib/kbd/keymaps/i386/include/linux-keys-bare.inc -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/include/linux-keys-bare.inc
/lib/kbd/keymaps/i386/include/euro1.map.gz -> /tmp/initrd.txR0Kd/lib/kbd/keymaps/i386/include/euro1.map.gz
/etc/sysconfig/i18n -> /tmp/initrd.txR0Kd/etc/sysconfig/i18n
/bin/setfont -> /tmp/initrd.txR0Kd/bin/setfont
/lib/kbd/consolefonts/latarcyrheb-sun16.psfu.gz -> /tmp/initrd.txR0Kd/lib/kbd/consolefonts/latarcyrheb-sun16.psfu.gz
/lib/udev/console_init -> /tmp/initrd.txR0Kd/lib/udev/console_init
/lib64/libglib-2.0.so.0 -> /tmp/initrd.txR0Kd/lib64/libglib-2.0.so.0
/lib64//libglib-2.0.so.0.2000.1 -> /tmp/initrd.txR0Kd/lib64//libglib-2.0.so.0.2000.1
probing for modules for drm device card0
Adding graphics device card0
Looking for deps of module pci:v000010DEd00000640sv00003842sd0000C959bc03sc00i00: i2c-core nvidia
Adding module i2c-core
Adding module nvidia
resolving for GRAPHICSMODS
and that has items of i2c-core nvidia
Looking for deps of module i2c-core
Looking for deps of module nvidia: i2c-core
copy from `/lib/modules/2.6.29.4-167.fc11.x86_64/kernel/drivers/i2c/i2c-core.ko' [elf64-x86-64] to `/tmp/initrd.txR0Kd/lib/modules/2.6.29.4-167.fc11.x86_64/i2c-core.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.29.4-167.fc11.x86_64/extra/nvidia-173xx/nvidia.ko' [elf64-x86-64] to `/tmp/initrd.txR0Kd/lib/modules/2.6.29.4-167.fc11.x86_64/nvidia.ko' [elf64-x86-64]
/sbin/plymouthd -> /tmp/initrd.txR0Kd/bin/plymouthd
........
........
Adding module scsi_wait_scan
copy from `/lib/modules/2.6.29.4-167.fc11.x86_64/kernel/drivers/scsi/scsi_wait_scan.ko' [elf64-x86-64] to `/tmp/initrd.txR0Kd/lib/modules/2.6.29.4-167.fc11.x86_64/scsi_wait_scan.ko' [elf64-x86-64]
This initrd uses dynamic shared objects.
Adding dynamic linker configuration files.
/etc/ld.so.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf
/etc/ld.so.conf.d/kernel-2.6.29.4-167.fc11.x86_64.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf.d/kernel-2.6.29.4-167.fc11.x86_64.conf
/etc/ld.so.conf.d/mysql-x86_64.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf.d/mysql-x86_64.conf
/etc/ld.so.conf.d/nvidia-lib64.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf.d/nvidia-lib64.conf
/etc/ld.so.conf.d/xulrunner-64.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf.d/xulrunner-64.conf
/etc/ld.so.conf.d/qt-x86_64.conf -> /tmp/initrd.txR0Kd/etc/ld.so.conf.d/qt-x86_64.conf
Running ldconfig
#
After rebooting your system, if you use dmesg or lsmod, you will see that the nvidia driver was loaded instead of the nouveau driver.

You will also see that for some reason Plymouth no longer runs with a graphical splash screen if it previously did so.  Plymouth is the replacement for the old RedHat Graphical Boot (RHGB).  It was written by Ray Strode, Kristian Hogsberg and Peter Jones of Redhat and first shipped in Fedora 10.

Finally, you do not need to modify your xorg.conf file for Fedora 11.  It should just work.
 

Scripting D-Bus

D-Bus (Desktop Bus) is a low-latency, low-overhead, easy-to-use message bus technology which supports application launch and linking.  It is primarly used on GNU/Linux desktops but has been ported to other platforms including Microsoft Windows and Apple Mac OS X.  This post provides a quick overview of D-Bus concepts, some history, and some examples of how to use D-Bus in your shell scripts.

Originally both the KDE and GNOME desktop projects used CORBA for inter-application communication.  Over time however, for various reasons, KDE migrated from CORBA to Desktop Comunications Protocol (DCOP) and GNOME migrated to Bonono.  This lead to the situation where GNU/Linux desktop distributions had to support two different inter-application lauch and linking models and many standard desktop applications could not communicate seamlessly with each other.  To ameliorate this unsatisfactory situation, D-Bus (the name was suggested by Harri Porten) was conceived and developed by Red Hat as part of the freedesktop.org project.  The design of D-Bus was heavily influenced by DCOP.  From the start, it was designed to be a replacement for the two competing technologies.   The initial source code module was created by Havoc Pennington in late 2002.  Development was quite slow with many changes to the wire protocol.  However by 2006 the specification was relatively stable.  First GNOME and then KDE made the decision to transition to D-Bus in order to support a single unified applcation linking and lauching technology on GNU/linux desktops.

In many ways D-Bus is similar to Sun Microsystems ToolTalk which is the undelying technology in Common Desktop Environment, and Microsoft's Object Linking and Embedding (OLE) technology.



The basic D-Bus protocol is a low latancy peer-to-peer or client-server binary protocol.  It is not intended for inter-machine use but rather for intra-machine use.  It works in terms of messages rather than byte streams.  A message bus is used when many-to-many communication is desired.  Normally applications communicate via such a message bus but direct application-to-application communication is also possible.

When communicating on a message bus, applications can query which other applications and services are available, as well as activate one on demand.  A daemon, or service, must be launched before any applications can connect to a message bus. This daemon is responsible for keeping track of the applications that are connected and for properly routing messages from source to destination.  The D-Bus specification defines two well-known buses called the system bus and the session bus.  These buses are special in that they have well-defined semantics and associated services.

A message bus can start (launch) an application on behalf of another application.  An application that can be started in this way is called a service and must have a well-known name.  To find an application corresponding to a particular name, the bus daemon looks for service description files which are XML files that map names to applications.  Different message buses will look for these files in different places on a system. Once the application is launched, it registers a service name.  Service names use reverse domain syntax (similar to Java), e.g org.freedesktop.Notifications.

D-Bus is object-orientated and supports the notion of named object interfaces.  As in C++, a method is an operation on an instantiated object.  Methods may have optional typed parameters and may return typed values.  Signals are broadcasts from an object to any interested observer.  All methods, method returns, signals, errors, etc. are encoded as D-Bus messages consisting of a packet header with source and destination addresses, a type signature and the body containing the parameters (for signals and method calls) or the return values (for a method return).  The type signature describes the types of the data contained within the message.  D-Bus uses interfaces to provide a namespacing mechanism for methods.  An interface is a group of related methods and signals, identified by a name which is a series of dot-separated components starting with a reversed domain name.

An application can expose one or more objects.  An object path is used to specify the address of each object.  The syntax of an object path is similar to that of the full pathname of a file on a Unix platform.  For example, /org/freedesktop/Notification is the object path to an object provided by the org.freedesktop.Notification service.  Service names, interface names and object paths do not have to be related in terms of their names but in many cases they are with the with the object path typically being a slashed version of the dotted service name as in the above example.  Messages buses can also expose interfaces, i.e. org.freedesktop.DBus.

The D-Bus specification mandates two special D-Bus interfaces - org.freedesktop.DBus.Introspect and org.freedesktop.DBus.Properties.  For our first example, let us ask the system message bus to list all it's methods.
dbus-send --system --print-reply --reply-timeout=2000 \
--type=method_call --dest=org.freedesktop.DBus \
/org/freedesktop/DBus \
org.freedesktop.DBus.Introspectable.Introspect

method return sender=org.freedesktop.DBus -> dest=:1.51 reply_serial=2
string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
<interface name="org.freedesktop.DBus.Introspectable">
<method name="Introspect">
<arg name="data" direction="out" type="s"/>
</method>
</interface>
<interface name="org.freedesktop.DBus">
<method name="Hello">
<arg direction="out" type="s"/>
</method>
<method name="RequestName">
<arg direction="in" type="s"/>
<arg direction="in" type="u"/>
<arg direction="out" type="u"/>
</method>
<method name="ReleaseName">
<arg direction="in" type="s"/>
<arg direction="out" type="u"/>
</method>
<method name="StartServiceByName">
<arg direction="in" type="s"/>
<arg direction="in" type="u"/>
<arg direction="out" type="u"/>
</method>
<method name="UpdateActivationEnvironment">
<arg direction="in" type="a{ss}"/>
</method>
<method name="NameHasOwner">
<arg direction="in" type="s"/>
<arg direction="out" type="b"/>
</method>
<method name="ListNames">
<arg direction="out" type="as"/>
</method>
<method name="ListActivatableNames">
<arg direction="out" type="as"/>
</method>
<method name="AddMatch">
<arg direction="in" type="s"/>
</method>
<method name="RemoveMatch">
<arg direction="in" type="s"/>
</method>
<method name="GetNameOwner">
<arg direction="in" type="s"/>
<arg direction="out" type="s"/>
</method>
<method name="ListQueuedOwners">
<arg direction="in" type="s"/>
<arg direction="out" type="as"/>
</method>
<method name="GetConnectionUnixUser">
<arg direction="in" type="s"/>
<arg direction="out" type="u"/>
</method>
<method name="GetConnectionUnixProcessID">
<arg direction="in" type="s"/>
<arg direction="out" type="u"/>
</method>
<method name="GetAdtAuditSessionData">
<arg direction="in" type="s"/>
<arg direction="out" type="ay"/>
</method>
<method name="GetConnectionSELinuxSecurityContext">
<arg direction="in" type="s"/>
<arg direction="out" type="ay"/>
</method>
<method name="ReloadConfig">
</method>
<method name="GetId">
<arg direction="out" type="s"/>
</method>
<signal name="NameOwnerChanged">
<arg type="s"/>
<arg type="s"/>
<arg type="s"/>
</signal>
<signal name="NameLost">
<arg type="s"/>
</signal>
<signal name="NameAcquired">
<arg type="s"/>
</signal>
</interface>
</node>
"
The following command lists out the names of services which can be activated (launched).
dbus-send --system --print-reply --reply-timeout=2000 \
--type=method_call --dest=org.freedesktop.DBus \
/org/freedesktop/DBus \
org.freedesktop.DBus.ListActivableNames

method return sender=org.freedesktop.DBus -> dest=:1.68 reply_serial=2
array [
string "org.freedesktop.DBus"
string "org.fedoraproject.Config.Services"
string "org.gnome.CPUFreqSelector"
string "org.freedesktop.ConsoleKit"
string "org.freedesktop.PackageKitAptBackend"
string "org.freedesktop.PackageKit"
string "org.freedesktop.NetworkManagerSystemSettings"
string "org.freedesktop.PackageKitTestBackend"
string "org.gnome.ClockApplet.Mechanism"
string "org.freedesktop.PolicyKit"
string "fi.epitest.hostap.WPASupplicant"
string "org.gnome.GConf.Defaults"
string "org.gnome.SystemMonitor.Mechanism"
string "org.freedesktop.nm_dispatcher"
]
Instead of using dbus-send which requires a number of parameters, a simpler utility to use is dbus which is part of the Google dbus-cli package.  Here is some sample output.
bash-3.2$ ./dbus
org.freedesktop.DBus
org.freedesktop.Notifications
org.freedesktop.PowerManagement
com.redhat.imsettings.IMInfo
org.gnome.SessionManager
org.gnome.GConf
org.freedesktop.PackageKit
com.redhat.imsettings
org.gnome.SettingsDaemon
com.redhat.setroubleshoot
org.gnome.ScreenSaver
org.bluez.applet
com.redhat.imsettings.GConf
Another useful utility is qdbus.
# list all GNOME-related  buses 
$ qdbus | grep gnome
org.gnome.SessionManager
org.gnome.SettingsDaemon
org.gnome.ScreenSaver
org.gnome.GConf

# list ScreenSaver interfaces
bash-3.2$ qdbus org.gnome.ScreenSaver
/

# list methods for ScreenSaver interface
$ qdbus org.gnome.ScreenSaver /ScreenSaver
method QString org.freedesktop.DBus.Introspectable.Introspect()
signal void org.gnome.ScreenSaver.ActiveChanged(bool new_value)
signal void org.gnome.ScreenSaver.AuthenticationRequestBegin()
signal void org.gnome.ScreenSaver.AuthenticationRequestEnd()
method void org.gnome.ScreenSaver.Cycle()
method bool org.gnome.ScreenSaver.GetActive()
method uint org.gnome.ScreenSaver.GetActiveTime()
method QStringList org.gnome.ScreenSaver.GetInhibitors()
method bool org.gnome.ScreenSaver.GetSessionIdle()
method uint org.gnome.ScreenSaver.GetSessionIdleTime()
method uint org.gnome.ScreenSaver.Inhibit(QString application_name, QString reason)
method void org.gnome.ScreenSaver.Lock()
signal void org.gnome.ScreenSaver.SessionIdleChanged(bool new_value)
signal void org.gnome.ScreenSaver.SessionPowerManagementIdleChanged(bool new_value)
method void org.gnome.ScreenSaver.SetActive(bool value)
method void org.gnome.ScreenSaver.SimulateUserActivity()
method uint org.gnome.ScreenSaver.Throttle(QString application_name, QString reason)
method void org.gnome.ScreenSaver.UnInhibit(uint cookie)
method void org.gnome.ScreenSaver.UnThrottle(uint cookie)

# retrieve session idle time. Zero in this case as I have been working on this post.
$ qdbus org.gnome.ScreenSaver /ScreenSaver org.gnome.ScreenSaver.GetSessionIdleTime
0

# activate the screen saver - may or may not lock depending on settings
$ qdbus org.gnome.ScreenSaver /ScreenSaver org.gnome.ScreenSaver.SetActive True

# lock screen using the screensaver
$ qdbus org.gnome.ScreenSaver /ScreenSaver org.gnome.ScreenSaver.Lock

# query whether this computer can be suspended?
$ qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.CanSuspend
true
You can also query devices via HAL as the following examples show.
$ dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.DBus.Introspectable.Introspect

method return sender=:1.0 -> dest=:1.106 reply_serial=2
string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
<interface name="org.freedesktop.DBus.Introspectable">
<method name="Introspect">
<arg name="data" direction="out" type="s"/>
<method>
<interface>
<interface name="org.freedesktop.Hal.Device">
........
<interface>
<interface name="org.freedesktop.Hal.Device.SystemPowerManagement">
........
<interface>
<interface name="org.freedesktop.Hal.Device.CPUFreq">
........
<method name="GetCPUFreqAvailableGovernors">
<arg name="return_code" direction="out" type="as"/>
<method>
<interface>
<node>
"

$ dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.CPUFreq.GetCPUFreqAvailableGovernors

method return sender=:1.0 -> dest=:1.109 reply_serial=2
array [
string "ondemand"
string "userspace"
string "performance"
]

$ dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/Manager \
org.freedesktop.Hal.Manager.GetAllDevices

method return sender=:1.0 -> dest=:1.115 reply_serial=2
array [
string "/org/freedesktop/Hal/devices/volume_part_1_size_403367936"
string "/org/freedesktop/Hal/devices/net_46_b2_32_e5_29_04"
string "/org/freedesktop/Hal/devices/computer_logicaldev_input_0"
string "/org/freedesktop/Hal/devices/usb_device_45e_734_noserial_if0_logicaldev_input"
string "/org/freedesktop/Hal/devices/usb_device_45e_734_noserial_if1_logicaldev_input"
string "/org/freedesktop/Hal/devices/computer_logicaldev_input"
string "/org/freedesktop/Hal/devices/volume_uuid_9e1859de_0cf0_4048_96f5_4ef32ac904f7"
string "/org/freedesktop/Hal/devices/computer"
string "/org/freedesktop/Hal/devices/volume_part2_size_205632000"
string "/org/freedesktop/Hal/devices/volume_uuid_a332a6d6_a034_4f19_b470_bacf7ffa81e2"
string "/org/freedesktop/Hal/devices/volume_uuid_RyytQp_f73U_LzdN_6JjC_08yN_Aw3e_p3fNF1"
string "/org/freedesktop/Hal/devices/storage_model_DVD_Writer_1070d"
string "/org/freedesktop/Hal/devices/platform_serial8250_serial_platform_1"
string "/org/freedesktop/Hal/devices/storage_serial_SATA_ST3500320AS_9QM49NMQ"
string "/org/freedesktop/Hal/devices/storage_serial_SATA_ST3500320AS_9QM4GKDK"
.........
]

$ dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/storage_model_DVD_Writer_1070d
org.freedesktop.Hal.Device.GetProperty string:'info.vendor'

method return sender=:1.0 -> dest=:1.120 reply_serial=2
string "HP"
While D-Bus was not really designed with shell scripting in mind, it is possible to use various utilities to access system and session data via D-Bus.  I hope you have not found this post too long-winded and that you will go away and experiment with D-Bus on your own computer.  Unfortunately there is a lot of out-of-date information, terminology and examples on the Internet relating to D-Bus.  Always refer back to the specification when in doubt.  All the examples included on this port were tested on Fedora 10.

P.S.  I plan to cover scripting D-Bus signals in a future post.
 

Scripting HAL

Recent releases of Fedora and other GNU/Linux distributions include a Hardware Abstraction Layer (HAL) which is used to support device plug-and-play capabilities.  In this post I will show you how your shell scripts can use HAL to retrieve device and system information.

The term HAL is overloaded as it used to refer both to a specification and the actual software which implements the specification.  From an application developers viewpoint, HAL is way to enumerate the capabilities and features of hardware attached to a system and receive notification when something about the hardware changes.

First, a very quick overview of HAL.  Each item of physical hardware in a computer is regarded as being an device object which identified by a Unique Device Identifier (UDI).  Associated with each device object is a variable set of well-defined typed key-value pairs (or metadata) called device properties which describe what each device object represents together with its properties.  Some device properties are derived from the actual physical hardware, some are merged from XML-formatted files, known as Device Information Files, and some are derived from the actual device configuration.  Mandatory device properties are defined in the HAL specification.



A HAL daemon is used to maintain and update the list of device objects forming a hardware configuration and is notified when devices are added or removed.  HAL also provides callbacks so that the operating system and applications can react to hardware configuration changes in order to maintain system policy.  An example of such a callback and policy is when you plug in a USB memory stick HAL automatically creates a mount point and mounts the device.

For a good backgrounder on HAL, see this article Making Hardware Just Work by Havoc Pennington.  For more detailed information, you should read the HAL Specification and the HAL project page at freedesktop.org.

A number of command line utilities are provided for accessing and manipulating device objects.



















hal-disable-pollingdisable polling on drives with removable media
hal-find-by-capabilityfind device objects by capability matching
hal-find-by-propertyfind device objects by property matching
hal-get-propertyget a property from a device object
hal-is-caller-locked-out  determine if caller is locked out
hal-is-caller-privilegeddetermine if caller is privileged
hal-locklock an interface
hal-set-propertyset a property on a device object
lshallist devices objects and properties

For the purposes of this post, we are only interested in a small number of the above utilities, i.e. those utilities which locate and return information about device objects.

Here is a simple use of the hal-find-by-property utility to retrieve a list of network interfaces.
$ hal-find-by-property --key linux.subsystem --string net
/org/freedesktop/Hal/devices/net_3a_67_56_92_fb_73
/org/freedesktop/Hal/devices/net_computer_loopback
/org/freedesktop/Hal/devices/net_00_1c_c0_6d_8a_f7
The HAL specification specifies a system namespace which contains information about a system and it's currently running kernel.  The following script retrieves certain information from the system namespace.
udi=$(hal-find-by-property --key info.product --string Computer)
printf "Board Manufacturer: $(hal-get-property --udi $udi --key system.board.vendor)\n"
printf " Model: $(hal-get-property --udi $udi --key system.board.product)\n"
printf " Version: $(hal-get-property --udi $udi --key system.board.version)\n"
printf " Serial No.: $(hal-get-property --udi $udi --key system.board.serial)\n"
printf " Release Date: $(hal-get-property --udi $udi --key system.firmware.release_date)\n"
printf " Bios Version: $(hal-get-property --udi $udi --key system.firmware.version)\n"
printf " Motherboard UUID: $(hal-get-property --udi $udi --key system.hardware.uuid)\n"
Here is the output from the computer which I used to write this post.
Board Manufacturer: Intel Corporation
Model: DX48BT2
Version: AAE26191-205
Serial No.: BQBQ8280004G
Release Date: 08/07/2008
Bios Version: BTX3810J.86A.1814.2008.0807.2334
Motherboard UUID: 2237F666-4F75-11DD-894F-0007E9747DB3
The next example retrieves certain information about all the storage devices on a system using the volume capability.  The volume namespace is for device objects that represent storage devices with a filesystem that are mountable.  Such device objects have the capability volume.
for udi in $(/usr/bin/hal-find-by-capability --capability volume)
do
mount=$(hal-get-property --udi $udi --key volume.mount_point)
device=$(hal-get-property --udi $udi --key block.device)
label=$(hal-get-property --udi $udi --key volume.label)
fstype=$(hal-get-property --udi $udi --key volume.fstype)
echo "$device $mount $fstype $label"
done
Here is sample output from this script.
/dev/sda1  /boot      ext3  /boot
/dev/sdb2 /abac ext3 /abac
/dev/sdb1 /home/fpm ext3 fpm
/dev/sda2 LVM2_member
/dev/sdc1 LVM2_member
/dev/sdc2 LVM2_member
You can also drill down and return information about specific devices such as an optical drive, i.e. device objects which have a capability of cdrom.
for i in $(hal-find-by-property --key storage.drive_type --string cdrom)
do
printf "Manufacturer: $(hal-get-property --udi $i --key storage.vendor)\n"
printf " Model: $(hal-get-property --udi $i --key block.device)\n"
printf " Bus: $(hal-get-property --udi $i --key storage.model)\n"
printf " Path: $(hal-get-property --udi $i --key storage.bus)\n"
done
Here is the output for the computer which I am using to write this post.  It contains a single DVD RW drive.
Manufacturer: HP
Model: /dev/sr0
Bus: DVD Writer 1070d
Path: pci
In many cases there are multiple ways of retrieving the information you want.  For example, here is another way of retrieving the same information, together with details of the volume label and mount point if there is a disk in the drive, using the storage.cdrom capability.
for udi in $(/usr/bin/hal-find-by-capability --capability storage.cdrom)
do
device=$(hal-get-property --udi $udi --key block.device)
vendor=$(hal-get-property --udi $udi --key storage.vendor)
model=$(hal-get-property --udi $udi --key storage.model)
if [[ $(hal-get-property --udi $udi --key storage.removable.media_available) = true ]]
then
parent_udi=$(hal-find-by-property --key block.storage_device --string $udi)
mount=$(hal-get-property --udi $parent_udi --key volume.mount_point)
label=$(hal-get-property --udi $parent_udi --key volume.label)
fi
printf "$vendor $model $device $mount $label\n"
done
Here is the output from this script when there is a DVD in the drive followed by when there is not a DVD in the drive.
$ ./findodrive
HP DVD Writer 1070d /dev/sr0 /media/Kota_Kinabalu1 Kota_Kinabalu1
$ ./findodrive
HP DVD Writer 1070d /dev/sr0
Here is a script to list details about all removable USB storage drives that are currently installed on your system.
#!/bin/ksh93
#
# list attached USB storage devices
#

for udi in $(/usr/bin/hal-find-by-capability --capability storage)
do
device=$(hal-get-property --udi $udi --key block.device)
vendor=$(hal-get-property --udi $udi --key storage.vendor)
model=$(hal-get-property --udi $udi --key storage.model)
if [[ $(hal-get-property --udi $udi --key storage.bus) = "usb" ]]
then
parent_udi=$(hal-find-by-property --key block.storage_device --string $udi)
mount=$(hal-get-property --udi $parent_udi --key volume.mount_point)
label=$(hal-get-property --udi $parent_udi --key volume.label)
media_size=$(hal-get-property --udi $udi --key storage.removable.media_size)
size=$(( ceil(media_size/(1000*1000*1000)) ))
printf "$vendor $model $device $mount $label "${size}GB" \n"
fi
done
And here is the output when two USB thumb drives are present.
./listusb   
Kingston DataTraveler 2.0 /dev/sdd /media/KINGSTON KINGSTON 1GB
Kingston DataTraveler 2.0 /dev/sdc /media/USB-4GB USB-4GB 4GB
$
Well that is about all for now.  You should have gained sufficient information from this post to go away and experiment on your own system. 

Remember, however, that the HAL specification and it's implementation in GNU/Linux distributions is still somewhat in a state of flux.  The above examples worked on Fedora 10 as of the date of this post.  If an example does not work on your system, I recommend that you first check the output from the lshal utility to see if the device object and associated device properties are instantiated on your system.  You can use udevadm --monitor to see what kernel events are being pushed out to user space.  HAL monitors these events.  You can also use lshal --monitor to see what events HAL emits to user space.