Bug 99568

Summary:	/etc/init.d/splash forces local to run before it normally would
Product:	Gentoo Linux	Reporter:	Matt Beswick (Soir) <soir>
Component:	Current packages	Assignee:	Michal Januszewski (RETIRED) <spock>
Status:	RESOLVED FIXED
Severity:	minor
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:	fixed in dev tree
Package list:		Runtime testing required:	---

Description Matt Beswick (Soir) 2005-07-19 12:33:08 UTC

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. ;) )

Comment 1 Michal Januszewski (RETIRED) gentoo-dev

2005-08-21 12:53:30 UTC

Fixed in 1.1.9.9.