[Splashy-devel] Splashy: initramfs done (?)

[Tim Dijkstra]

Op Mon, 25 Sep 2006 01:51:59 -0400
schreef Luis <lemsx1 at gmail.com>:

> Hello all,
> 
> This is just to inform you that my work to get the bug of "running
> splashy from initramfs" fixed is done. This is what needs to be done
> in order to use Splashy from initramfs:

Hurray!

> 1. edit /etc/default/splashy and set ENABLE_INITRAMFS
> 2. run update-initramfs -u to allow our hook script to do the right
> thing 
> 3. do not use splashy-init, use
> trunk/scripts/etc/lsb-base-logging.sh which has to be copied
> to /etc/lsb-base-logging.sh (hint:  update-rc.d -f splashy-init
> remove). (note to self: we need to remove splashy-init from being
> installed in the debian package and in our distrib tarball.
> splashy-update-progress-steps and lsb-base-logging.sh will take over
> that role) 
> 4. cp scripts/splashy-update-progress-steps to /etc/init.d
> and do: update-rc.d splashy-update-progress-steps stop 01 0 6 .

The packaging for the 0.3 branch does this (points 2,3 and 4) already.
Have a look in 0.3/debian.


> 5. patch /etc/init.d/keymap.sh and /etc/init.d/console-screen.sh like:
> #!/bin/sh
> pidof splashy > /dev/null && exit 0
> ...
> In other words, if splashy is running, do not bother to run keymap.sh
> (which stops splashy and waits for input in tty2) or console-screen.sh
> (which stops splashy and only CTRL+C seems to work on tty2).
> /etc/lsb-base-logging.sh will do the right thing and run these scripts
> again when the percentage goes to 100% (when gdm/kdm/xdm calls
> log_msg_end() or when X is detected running, our percentage goes to
> 100% automatically)

> As of now lsb-base-logging.sh is logging to /tmp/splashy.log a few
> things just to keep track of the system performance and the progress
> state. This will be improved before release (splashy 0.2).
> 
> There are a few things that bother me (if you have answers, please
> provide):
> 
> 1. splashy seems to launch 7 processes when running from initramfs.
> not sure if the main thread never exits or if it's because the
> processes from initramfs can't fork()
> 2. splashy uses almost 100% of the CPU during boot. i still don't know
> why is this, but that only happens from initramfs

Hmm, I hurrayed to early :( This is what I saw a few weeks ago. I
thought this was the infamous 'initramfs bug'...

> 3. splashy never gets to 100% progress. right before rmlogin is
> supposed to run, the system waits too long and splashy just exits,
> which means that console-screen and keymap don't get fixed and some
> splashy processes are left running (ps ax | grep splashy shows about 5
> of them)
> 4. splashy now runs on tty8, this creates a problem when using
> "splashy test" as it doesn't go back to the terminal from which we
> started
> 5. splashy-update-progress-steps need to be run from
> /etc/rcS.d/S01splashy-update-progress-steps or another script... and
> it should do:
> 
> if runlevel is 0 or 6,
>   see if splashy is not running and launch it with shutdown as
> argument then continue saving the scripts that make up the progress in
> /lib/splashy/$RUNLEVEL-progress
> 
> if runlevel is S
>   see if splashy is not running and launch it with boot as argument,
>   then exit (because the filesystem is probably read-only and we
> can't calculate the progress steps needed, as they need to be saved
> in /lib/splashy/*)

This (5) is also done in the 0.3 three branch.
 
> I hope I'm not missing something here. I'll add more as we go. If we
> get these minor issues resolved, we can release splashy as 0.2 and
> move on with life.

I think there still is the major issue of splashy taking 100% CPU when
launched from initramfs. This is really a show-stopper. On my machine
it adds 90s to the boottime.

Unfortunately I don't have time to work on this the coming time, but
I think debugging should concentrate on this. The other issues are
already done in 0.3 or should have a quick fix. I'm really stumped
about the 100% CPU thing. If somebody has time, he/she should try to
run a very simple directfb program (that only draws a picture on the
screen) from initramfs to see if it is the directfb library that
creates the problem.

grts Tim