[Splashy-devel] Bug#505270: A solution

[Tim Richardson]

Thanks to #splashy and Mattkijs Kooijman, we have a solution.

It's not a very good solution, but it proves we know what the problem
is:

The solution is to delay the init process for one or two seconds after
splashy boot


ie change /usr/share/initramfs-tools/scripts/local-premount/splashy
and add
sleep 2  #smaller values probably work


so that the code looks like



grep -q '\(VESA\|VGA\)' /proc/fb || exit

/sbin/splashy boot
sleep 2  #smaller values probably work




The problem (my theory)

the splashy scripts forks and exits quickly, while its child process
does the work of initialising directfb.
This fast exit of splashy lets the init process continue.  (thanks
Matthijs)

On my computers, and other computers, this sets up a race condition.
It seems that initramfs is being unmounted while the splashy children
are working to setup directfb. 
directfb finds that the file system has gone by the time the call to
CreatFont happens. 

This is probably only a matter of milliseconds. In v 3.10, the earlier
start of splashy boot avoided this problem.

The workaround hack to set up a directfb log file also probably causes
enough of a delay to avoid the problem (as guessed by directfb
developers)

A sleep in local-premount at the end of the splashy script is a crude
mechanism to buy enough time for the child process to finish its
initialisation of directfb