bootsplash

A couple of days ago I installed the Debian bootsplash package and rebooted. It simply didn't work, so I went to the internet to find out why. The first site I came across was bootsplash.org and one of the first things I found, was that you need to patch your kernel.

bootsplash.org points you to:

ftp://ftp.openbios.org/pub/bootsplash/kernel/

which has patches for various (including the 2.6.15 2.6.18 2.6.20 and 2.6.21) kernels.

I am using the 2.6.22 kernel and the 2.6.21 kernel patch failed, so the first thing I had to do, was patch the patch.

So, here is a 2.6.22 patch (md5 = 138bd6104e94922464f5866b6a358903).

Update: This page: http://fatcat.ftj.agh.edu.pl/~przyboro/other/bootsplash/

offers patches for the 2.6.19, 2.6.21, 2.6.22, 2.6.23 and 2.6.24 kernels and the rc, rc.S files. I have not tried them.

At the top of every bootsplash.org page, is the prominent notice:

NOTE: The bootsplash project has been superseded by Splashy, a boot splash implementation that does not require a kernel patch and is a lot easier to configure. We suggest you go and update to Splashy. This page will stay up for convenience reasons but no new patches will be posted.

So, I tried Splashy,... and all I can say is, DON'T BOTHER.

Who wants a bootsplash that adds an extra 30 seconds to your boot time and has a progress bar that seems to be tracking the progress of a learner driver. The fact that Splashy does not work well, is not totally the fault of its author, it is simply that the whole idea is fatally flawed. In order, to not use a simple kernel patch, the whole frame-buffer machinery has to be crammed into the initial ram disk, then unpacked and fired up at boot, and that all takes extra time.

SuSE will never change from bootsplash, to Splashy. You have to wonder; Why would one want to close down a perfectly acceptable bootsplash arrangement, for one that hardly works and has no hope of working well? Actually, don't wonder. This is just another, albeit subtle, way to sabotage Linux.

It is reminiscent of the NTFS (read-write) kernel driver affair, where the kernel driver was abandoned in favor of the NTFS/fuse user-space driver. Of course, no user-space driver will ever compete favorably with Microsoft's NTFS kernel drivers. But then, that was the whole point, wasn't it?

By lying about the dangers of the NTFS kernel driver, certain kernel "developers" were able to have the driver expelled from the Linux kernel and the NTFS/fuse project crowned as the only way forward. Of course, if the kernel "developers" had actually been concerned about the dangers of the driver, they would have fixed the offending code, not thrown the code away.

Save the kernel and patch somewhere. I chose /usr/src/.

 mv bootsplash-3.1.6-2.6.22.diff.bz2 linux-2.6.22.tar.bz2 /usr/src/
 cd /usr/src/

Unpackage everything.

 tar -xf linux-2.6.22.tar.bz2
 bunzip2 bootsplash-3.1.6-2.6.22.diff.bz2

Change to the new kernel source directory and patch the kernel.

 cd /usr/src/linux-2.6.22/
 patch -p1 < ../bootsplash-3.1.6-2.6.22.diff

Copy your current kernel configuration file (that came with your distro) to .config

 cp /boot/current-kernel-config /usr/src/linux-2.6.22/.config

Replace "current-kernel-config" with whatever it's real name is. By the way, a gzipped copy of the running kernel's configuration, is often available at /proc/config.gz. Now, run menuconfig (or xconfig or gconfig)

 make menuconfig

Make sure the following are set (or unset, as the case maybe):

Device Drivers ---> Graphics support ---> <*> Support for frame buffer devices [*] VESA VGA graphics support [ ] Bootup logo ---> Bootsplash configuration ---> [*] Bootup splash screen Console display driver support ---> <*> Framebuffer Console support Device Drivers ---> Block devices ---> <*> RAM disk support

Make any other desired alterations to the configuration. Then build the kernel packages with:

 make binrpm-pkg   (SuSE Mandriva Red Hat)
 make deb-pkg   (Debian)

For help on compiling a kernel, see: Compiling yourself a new Kernel (with Reiser4 support).

If you are using Debian, you should install the packages:

bootsplash
bootsplash-theme-debian
linux-patch-bootsplash
sysv-rc-bootsplash

I have only installed the first 2 so far (as they were on the install DVDs). The 2nd package installs a bootsplash theme (the pictures that will be displayed and a configuration file). If you are not using Debian, then you will have to find and install a theme yourself (if you like, you can use the one from Debian).

If your distribution does not have pre-compiled packages, then you should download

bootsplash_3.3.orig.tar.gz

from Debian and compile, and install it, with the commands:

 tar -xf bootsplash_3.3.orig.tar.gz
 cd bootsplash-3.3/Utilities
 make

You have to install the programs by hand (ie, copy them to /usr/bin).

You may also wonder why bootsplash.org offers version 3.0.7 (which hasn't been current since 2004) from their "Kernel" page. Interestingly, a different version, though still not current, is offered from their "Userspace" page (version 3.1).

You may also wonder why bootsplash.org suggests that you run make splash instead of make.

The answer to the 2nd question is that make should make the programs splash, splashpbm, fbresolution, fbtruetype and fbmngplay, whereas, make splash, will only make the program splash. The answer to the 1st question should be becoming clear to you by now.

I said "should make" because one, fbmngplay, needs a patch to compile.

Since only Debian provides manual pages for the above commands (except splashpbm) I have packaged them here.

Now that you have the program splash, you can build a new initrd (initial ram disk) containing all the bootsplash apparatus. First, we should deal with the misdirection from bootsplash.org:

bootsplash.org suggests that you build a new initrd with the command:

/sbin/splash -s -f \
/etc/bootsplash/themes/yourtheme/config/bootsplash-1024x768.cfg \
>> /boot/initrd.splash

Now here, bootsplash.org, has strayed from the rule of "plausible deniability" (you do not lie to people unless you can excuse your lie as a simple mistake, or misunderstanding). The command given here could not possibly work, for any form of initrd that I am familiar with. There may be some rare varieties of initrd for which this command would work, however, I do not know of any.

Nearly all distributions (Debian SuSE Mandriva Red Hat etc) now use cpio archives for their initrd and they all compress their initrd with gzip. First, you cannot just dump a few files at the end of a cpio archive (as the above command does) and expect them to be recognized. Cpio archives just don't work that way. And even if you could, you would have to decompress the archive to have any prospect of success with the above command.

Previous to the adoption of cpio archives, initial ram disks, were most commonly, compressed ext2 filesystems images. The bootsplash.org command will not work for these older versions, either.

The bootsplash.org command would actually work, if you had compiled all necessary drivers into your kernel and thus did not use an initial ram disk, previous to installing bootsplash. Of course, almost no one would be in this situation. However, since bootsplash.org claim that you can update your previously existing initial ram disk with their command, you can be sure they intend to mislead you.

You may be wondering why bootsplash.org, and the other web-sites pushing this clearly false command, are misleading you in this way.

So how do you really create a new initial ram disk.

Install the initramfs-tools package. The Debian people have written a small program (a hook) telling update-initramfs (from the initramfs-tools package) to include the bootsplash file, whenever update-initramfs is run. However, a mistake in this program,

/usr/share/initramfs-tools/hooks/bootsplash, has to be corrected first.

Change the last line: splash -s -f $SPLASH_FILE > $DESTDIR/bootsplash

To: $SPLASH_BIN -s -f $SPLASH_FILE > $DESTDIR/bootsplash

Now run update-initramfs:

 update-initramfs -u -k 2.6.22   (u for update initramfs) or
 update-initramfs -c -k 2.6.22   (c for create initramfs)

If you are not running Debian, then you will have to manually unpack your current initrd file, add the bootsplash file and pack it up again. This is how you do it:

 cd /boot; mv initrd-2.6.22 initrd-2.6.22.old
 mkdir /boot/initrd.dir
 cd /boot/initrd.dir
 gunzip -c ../initrd-2.6.22.old > initrd
 cpio -vid < initrd
 rm initrd
 /usr/sbin/splash -s -f /path/to/config/bootsplash-1024x768.cfg > bootsplash
 find | cpio -o -H newc | gzip -9 > ../initrd-2.6.22
 cd /boot; rm -fr /boot/initrd.dir

Make the obvious changes (change initrd-2.6.22 to the name of your initrd, change /path/to/config... to the actual path to the bootsplash configuration). Note that the file you add to the initrd must be named bootsplash (you can use the script unpack to unpack the initrd, but you will still have to pack it by hand).

You may wonder why Linux's cpio, supports the old POSIX.1 format (the pre-1989 format) by default, and why the -c option, that is meant to switch to the "new" SVR4 format (the post-1989 format), "accidently" doesn't work.

Now you need to edit your /boot/grub/menu.lst file. Mine looks like:

title Debian GNU/Linux -- My Brand New Kernel 2.6.22 root (hd0,0) kernel /boot/vmlinuz-2.6.22 root=/dev/sda1 vga=791 splash=silent ro initrd /boot/initrd.img-2.6.22

The needed parameters are in red. The vga parameter determines the frame-buffer resolution:

vga=785 for 640x480
vga=788 for 800x600
vga=791 for 1024x768
vga=355 for 1152x864
vga=794 for 1280x1024
vga=798 for 1600x1200

These correspond to the VESA 16-bit modes. Apparently, if you pass vga as a boot parameter, the kernel assumes you will be using the VESA frame-buffer (which you have compiled into your kernel). It is possible to use various other frame-buffer devices, but since I haven't been able to get the NVIDIA frame-buffer device to work, I won't say anything more about this.

The default Debian 1024x768 theme worked (up to a point), however, a couple of 1280x1024 themes I tried, did not.

Some configuration file causes the bootsplash to flash quickly (6 times) part way though the boot. I haven't been able to track down the cause of this yet, but hopefully, I will soon, as it is rather distracting. This is the sort of thing you expect in a project that is being actively sabotaged.

It turns out that this little piece of probable sabotage, is Debian specific. This accident, certainly has plausible deniability. At some point, some package has added six lines, similar to

SCREEN_FONT_vc2=lat0-sun16

to the end of the file /etc/console-tools/config. These lines supposedly set the font on all the virtual terminals. They are totally unnecessary, and removing them stops the flashing.

The default Debian theme has a progress bar. Apparently, one can get that to work if one installs the sysv-rc-bootsplash package, but I haven't tried this yet either. I installed the sysv-rc-bootsplash package and things worked as advertised. I was disappointed that the bootsplash now allows a few lines of the startup text, and that the progress bar was quite jumpy, but it worked (including the animations).

I have many half completed guides, that were never published because they were not finished to my satisfaction. Lately, I have had a change of heart, and will publish some incomplete work, like this guide. Hopefully, this will not lead to you being too misinformed on the subject.