This is an odd thing to try and fix and I'm not sure how best to deal with it; I could hack it to my needs on this end but that's not really 'customising' and I'm loathe to do it... I have recently emerged splashutil and splash-themes-gentoo and elected not to have a bootsplash, which means no kernel parameters, just the adding of /etc/init.d/splash to a runlevel. I thought I'd like to have the tty splash up as soon as possible, which seems reasonable enough given the standard practice of initrd for the bootsplash screen, so I stuck it in boot runlevel, which may or may not be 'correct', I don't know. It doesn't matter, anyway, since when I did this and rebooted, /etc/init.d/local ran before it, even though local itself wasn't in any runlevel at the time (also odd: now it's in default, as it should be, but this makes no difference either). /etc/init.d/splash depends on local being run (and will choose to run it if it so wishes). Is there any real reason for this, and is this even a bug? :) (Afterthought: It's a bug if bug 34233 is, I suppose: splash and local seem similar to bootsplash and local. Then again, I appear to be querying the fix made there: sorry for stepping on toes. ;) )
Fixed in 1.1.9.9.
