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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
