To run Splashy from initramfs you need to create a new initramfs image. An initramfs image is a little system that is launched during the kernel's initalization, before the system starts.
During Splashy's installation Splashy sets everything up so you can get it integrated into initramfs whenever you wish by just running a single command.
But first you must edit /etc/default/splashy and set ENABLE_INITRAMFS=1 so that Splashy will integrate itself into future initramfs images.
Debian simplyfies this task greatly. Just run:
update-initramfs -u -t -k `uname -r`
When update-initramfs is done, you can reboot. Splashy will start right from (almost) the very beginning.
You have to use the correct image path, so check your bootloader configuration (/boot/grub/menu.lst for Grub), and look for the line which mentions initrd (Note: If you have more boot options, because you have more kernels installed for instance, you must look for the initrd line under the boot option which you are currently using). The 2.6.8.1-3-386 kernel, for example, usually uses the file initrd.img-2.6.8.1-3-386 which is located in the /boot directory. In order to make the initrd image you will have to do mkinitramfs -o /boot/initrd.img-2.6.8.1-3-386. You must replace /boot/initrd.img-2.6.8.1-3-386 with the correct initramfd file. Check uname -r to get a clue. Many systems work with just doing
mkinitramfs -o /boot/initrd.img-`uname -r`
When mkinitramfs is done, you can reboot. Splashy should work now.
Sadly, there is a bug in the way most systems handle unicode consoles. And avoiding it needs an additional tricky step.
You will need to find which /etc/init.d scripts use the commands /usr/bin/unicode_start and /usr/bin/unicode_stop.
These are used to set the font for all consoles as well as the keyboard mapping. If this is done while Splashy is running from initramfs, the boot process will stall. To avoid this do the following:
grep -li unicode_ /etc/init.d/*
This will let you see which initrc scripts use the unicode_* commands. You will need to then edit these scripts so that they do not execute the unicode_* command if Splashy is running. If the script contains a function called unicode_start_stop(), patch it in the following way:
unicode_start_stop()
{
# check if splashy is runing and skip this, we'll get run again later
pidof splashy > /dev/null && return
...
If your scripts do not use unicode_start_stop() function (console-screen.sh doesn't), you might want to edit it like:
#!/bin/sh # ... # check if splashy is runing and skip this, we'll get run again later pidof splashy > /dev/null && exit 0 ...
In other words, check if there is a splashy process running as early as possible and before running unicode_start/unicode_stop commands. If it is, skip unicode_*.
Finally, edit /etc/default/splashy again and set POST_EXEC_SERVICES to contain the names of the scripts you modified in the same order they are executed at boot time. For example:
POST_EXEC_SERVICES="keymap.sh console-screen.sh"
The fifo file splashy uses to get information about the boot/shutdown/etc progress is not accessible in the way from initramfs to real system. To walk around this, just edit your /etc/splashy/config.xml and set the fifo path to be at /dev/.initramfs/splashy.fifo like this:
<fifo>/dev/.initramfs/splashy.fifo</fifo>
Every time Splashy's config.xml file is updated the initramfs must be updated with it! Otherwise Splashy will not be aware of the changes and it will seem as if it was ignoring them.
Just before Splashy will start there (obviously) won't be a nice splash screen. Still some text will appear. This tip will help you prevent letter-fobia!
When you use GRUB, edit /boot/grub/menu.lst and
Now there won't be (almost) any text at boot time ;)
When you use LILO, edit /etc/lilo.conf and:
If you use a splash bitmap, you may want to add bmp-retain so that the lilo splash image is retained until text is output by the kernel instead of goign into text console as soon as lilo boots the kernel.
Now there wo't be any text at boot time ;)
If you are using a different boot manager you will have to open the corresponding config file and add quiet to wherever the kernel arguments have to be.
The following steps apply to qemu 0.8.0 and up (test under Ubuntu Dapper and Debian Sarge/Etch)
In order to create a 1GB image you have two choices, either use the provided qemu-img (preferred):
qemu-img create linux.img 1024M
Or write the image using dd like:
dd if=/dev/zero of=linux.img count=1000 bs=1M
qemu-img gives you a better advantage and a simpler syntax. Use -f qcow to create an image that can easily be expanded (later). Like:
qemu-img create -f qcow linux.img 1024M
First you will need to install Linux, if you already have an ISO with your installation:
qemu linux.img -net nic -net tap -boot d -cdrom dapper-install.iso
If you get an error message like warning: could not open /dev/net/tun: no virtual network emulation, install vtun package, run it ( /etc/init.d/vtun start) and set /dev/net/tun universally read-writable (chmod a+rw /dev/net/tun).
When asked about the IP to use in the installed OS, set it it 172.20.0.2 if you want to follow the rest of the instructions here.
After that you can simply launch qemu using:
qemu linux.img -net nic -net tap
Now if you want to enable internet access to your qemu host, you have to allow 172.20.0.2 to connect to your system under 172.20.0.1 and access the internet. The following steps guide you in the process. You *must* follow them in *exact* order.
If you are using a custom kernel (that is, a kernel you compiled yourself), make sure you have the folloing features compiled either built-in or as modules:
Install dnsmasq and edit /etc/dnsmasq.conf to contain interface=tap0
Restart dnsmasq to apply the configuration changes (in Debian systems: /etc/init.d/dnsmasq restart).
The following steps must be doen everytime you run qemu. You might want to run them in a script:
Start Qemu: qemu linux.img -net nic -net tap
Now to forward the internet connection, the easiest way to achieve this is using Firestarter and allow internet sharing (see http://www.fs-security.com/docs/kernel.php if you are using a custom/self-compiled kernel).
If you do not want to use firestarter, follow these steps:
Note: If you are using udev, you might have to run chmod a+rw /dev/net/tun every time before running qemu.
In kernel you might want to have NFSD, NFSD_V3, NFS_FS and NFS_V3 enabled in kernel. All those can be found in File systems → Network File System → NFS server support and File systems → Network File System → NFS file system support
Install an NFS server (in Debian systems, install nfs-kernel-server or nfs-user-server)
Edit /etc/exports to tell NFS the directories you wish to share. You must also tell the NFS server the access mode to that share (see man exports). For example: /home/Shared/tmp *(rw,async)
Restart the NFS server to make sure it reads the new configurationn and applies it inmediately. In Debian systems, run /etc/init.d/nfs-kernel-server restart or /etc/init.d/nfs-user-server restart (depending on the pakcage you installed)
Now from the qemu image you can mount the shared directory of the host system simply by mounting it. For example: mount 172.20.0.1:/home/user /mnt
You might want to add the mount instruction into /etc/fstab
Right now, you would have to chmod /dev/net/tun and setup the ip forwarding everytime you reboot. To avoid this, do the following:
#!/bin/sh
sudo sh -c 'ifconfig tap0 172.20.0.1 up;
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
echo "1" >/proc/sys/net/ipv4/ip_forward'
You can also try the kqemu kernel module which should dramatically increase Qemu's speed on your system, but that's out of the scope here.
Download and compile splashy on your system.
You can use the network share (NFS) to transfer and share files between the qemu image and the host system.
Reboot all you want now!
These instructions assume that you are using svk as your subversion (svn) client.
mkdir -p splashy cd /usr/src/splashy wget http://splashy.alioth.debian.org/splashy-bootstrap.dump.bz2 svk depotmap splashy ~/.svk/splashy bzcat splashy-bootstrap.dump.bz2 | svnadmin load --ignore-uuid ~/.svk/splashy svk sync /splashy/alioth svk co /splashy/local
If you want to create your own bootstrap file, just follow the following instructions:
svnadmin dump --deltas ~/.svk/splashy > splashy-bootstrap.dump # edit splashy-bootstrap.dump and remove the UUID line (3rd line in this file or so) bzip2 splashy-bootstrap.dump
The following steps assume that you compiled Splashy using:
cd /usr/src svn co svn://svn.debian.org/svn/splashy cd splashy/trunk/ ./autogen.sh --prefix=/usr/local --enable-debug # ./configure is run for you by autogen.sh. you only need to run autogen.sh once make
If you are using the debian package, you can do:
cd /usr/src svn co svn://svn.debian.org/svn/splashy cd splashy/trunk vi ../debian-related/trunk/debian/rules #make sure that the CONFIGURE line has --enable-debug ./script/make-debian dpkg -i /tmp/splashy_*.deb
Once Splashy is compiled and installed, the binary goes in /sbin/splashy. Running Splashy in test mode is as simple as:
/sbin/splashy test 2> /tmp/splashy_debug.log
Where /tmp/splashy_debug.log will have all the messages that Splashy prints to the screen before it starts.
Once Splashy is installed, you might want to add it to initramfs. To do that you will need to edit a few files:
/etc/default/splashy: you need to enable initramfs here
/usr/share/initramfs-tools/scripts/init-top/splashy: where it says: /sbin/splashy boot. Change it to say: /sbin/splashy boot 2> /dev/.initramfs/splashy_debug.log
/boot/grub/menu.lst: make sure that ”rw” is passed as a parameter to your kernel, instead of ”ro”
Now when you reboot your system, Splashy should log its output to the log file you specified (2> …). These messages are very straight forward and self-explanatory. Become familiar with the C source files for Splashy and you will be able to pin-point what the messages refer to.