initscripts getting very close

[Jasper Huijsmans]

On Fri, 31 Oct 2003 11:39:59 -0500
Chuck Mead <csm at lunar-linux.org> wrote:
...
> > Error stat(2)ing: "fd": no such file or directory
> >
> > This is before even devfsd gets mounted, so it could be from
> > from initlog or perhaps bash. I couldn't find anything in the
> > initlog
> > code. It doesn't do any harm apparently.
> 
> I might find this over the weekend... we'll see.
> 

I will be away this weekend, so I can't do more testing until next week.

> > I have a few questions:
> >
> > * our modutils / module-init-tools install an initscript to load all
> > modules listed in /etc/modules. The rc.sysinit doesn't seem to
> > provide
> > any such functionality. Should something like that be added or is it
> > provided somewhere else?
> 
> I think an initscript to accomplish this would be better than a
> modification to rc.sysinit.
> 

Personally, I like the way the old system uses /etc/rcS.d for system
initialization scripts. Makes it easy so keep functionality separated. I
have a feeling rc.sysinit tries to do a bit much. I only have a very
simple system set up, though, so perhaps the functionality can't be
easily separated at all.

> > * I have updated modules for metalog and fcron, should they be added
> > to
> > the init.d scripts in CVS? And, in general, new and old initscripts
> > are
> > not compatible, how should we handle this?
> 
> Yes... please add them to the init.d cvs module.
> 
> As to the new/old thing I think we are very close to being able to
> push
> this out to everyone so I am not sure what we should do but obviously
> we
> will have to take what's in init.d cvs and submit them to each init.d
> sub-dir in the moonbase or do a separate module which simply loads and
> overwrites what's already in init.d. Thoughts?
> 

Yeah, overwriting is fine IMO. With the proper warning when installing
the new initsystem.

> > * there is some kernel related code in rc.sysinit that is very
> > redhat-specific. Perhaps some of our kernel guru's can have a look.
> > Specifically, the part calling depmod and some code dealing with a
> > special redhat kernel library. This doesn't stop us from using it
> > now,
> > BTW, it simply is ignored.
> 
> Hmmmm.... gotta look at that.
> 
> > * rc.sysinit loads mousedev and keyboarddev if you have usb. This
> > creates FATAL error messages from the kernel. The modules are
> > probably
> > kernel 2.4 specific, but I'm not sure. Since we don't really support
> > 2.6
> > it may not be a problem.
> 
> Yes.. this is a 2.4/2.6 thing... they have different names under 2.6.
> 

perhaps check for 2.4 ?

case "$(uname -r)" in
	2.4.*) ... ;;
esac

> > * the initscripts package provides sys-unconfig functionality, that
> > makes rc.sysinit reset some system stuff on reboot. This calls
> > several redhat config utilities. It may be nice to add these to
> > lunar as
> > well, now that we have netconfig and ntsysv already: kbdconfig,
> > timeconfig, authconfig (pam setup?). Perhaps related to this:
> > pam_console_apply, which apparently sets up some pam permissions. I
> > have
> > no idea if this is at all possible.
> 
> I will look at this too but it's not a show stopper in the meantime.
> 

agreed

> > > Anyway it is rock solid here for me on two machines... and one of
> > > them
> > > is a lappie running pcmcia stuff!
> > >
> >
> > It works perfectly for me, but so did the old system ;-)
> 
> Not on servers it didn;t and a lot of exit code handling and some
> other
> stuff just never really got solid.
> 

I didn't mean to say it did, just that I can't compare ;-)

Have a nice weekend,

	Jasper