I'm working on a project to build my own distribution based on Linux From Scratch . I've been trying to get Bootsplash to work with a LiveCD and a netboot version of the distribution.  Unfortunately, using bootsplash with linux kernel 2.6's initramfs is not well documented.  Thus, I'm making notes about how I got it working here.

I've got a build system working that brings up the system via a netboot just fine, including use of a bootsplash image. That version creates an initrd image by simply using the splash command output to a file that is used as the initrd (because no real ramdisk image is needed for the netboot). Essentially, it works like this:

splash -s -f > initrd.splash

and the PXELINUX config file then looks like this:

LABEL bootsplash

    KERNEL vmlinux

    APPEND root=/dev/nfs rw nfsroot=192.168.0.100:/mnt/mythbox ip=dhcp vga=791 initrd=initrd.splash splash=silent

So this was a no brainer.  But what I really wanted was a LiveCD that would do the same thing.  The LiveCD needs a real ramdisk image at boot time.  With Linux 2.4 the way to create this image was to create a big, empty file, format it with ext2, mount it and fill it with your rootfs required for booting.  Then you simply appended the output from the splash command to that.  But with Linux 2.6 the initrd is now an initramfs, which is actually just a compressed cpio file.  Appending the image didn't seem to work.  

I dug around for quite some time trying to find an answer to this.  Buried deep in the archives of the Bootsplash forum was the answer.  The steps are:

1. Create your compressed cpio image for your initial ramdisk.  I call mine mythbox.gz, which is based on Busybox.
2. Create a splash data file using a command like this:   
3. Append the splash data file to the compressed cpio initial ramdisk image:  echo splashfile | cpio -o -H newc | gzip >> mythbox.gz
4. Make sure your isolinux.cfg file enables the bootsplash code.  The file should look something like this:

label linux
  kernel vmlinux
  append initrd=mythbox.gz vga=791 splash=silent ramdisk_size=128000 init=/sbin/init root=/dev/ram0

The initramfs image is now actually a multiarchive compressed cpio archive, which the kernel handles just fine.  Additionally, if you don't specify the splash= option (setting it to either silent or verbose) then the bootsplash code is not run and you won't get your bootsplash image.  The vga=791 option just forces the console display to use higher resolution, making the text look smaller. 

So now I have my LFS build system producing bootable versions for netboot and a LiveCD.  The netboot option will be used for debugging, since it's easier to test the distribution without having to burn a CD each time.  The CD version will be the production version, as it's sole purpose will be to manage a consumer device. 

Hang on a tick – this didn't work after cleaning up the build.  A little investigation found that I needed to copy the output file from the splash command to the busybox rootfs as bootsplash.  The question now is:  do you have to both of these (appended to initramfs and copied into rootfs) or just the latter?  More investigation is needed….

Update 2 

Okay, so it seems this is completely wrong.  What is required is to copy the splash image file to the rootfs of your initramfs.  You don't need to append the image to the compressed initramfs at all.  So the correct process is actually:

Build busybox and install it into a directory.  We'll call it /mnt/mythbox/busybox. 

1. Create a splash data file using a command like this: 
2. Copy splashfile to the top level of your busybox directory: cp splashfile /mnt/mythbox/busybox/bootsplash  Note that the filename in the busybox directory must be bootsplash.
3. Now build your compressed cpio image that will be your 2.6 initramfs.  You don't need to append the splash file to the compressed initramfs.

Now it works.  This makes sense, too, if you read the bootsplash patch in the init() function.  It tries to open the file "/bootsplash".  I can see how people thought you still needed to append the file because that's what you did with 2.4.  But I'm not sure why the information about placing the file in the root of the rootfs isn't posted somewhere else.

Anyway, this seems to work now.  I've verified it with several builds.