init requires /dev/vc devices

Rob Landley rob at landley.net
Fri Feb 17 19:28:30 UTC 2006


On Friday 17 February 2006 12:57 pm, Martin Michlmayr wrote:
> * Rob Landley <rob at landley.net> [2006-02-15 12:12]:
> > Lemme see if I understand this:
> >
> > You have an inittab telling busybox init to spawn things on three
> > consoles that either don't exist when you run init,
>
> No, they do exist because we create them before running init.

You seem to have ignored the word "either".

> > or are invalid device nodes.
>
> Right, on some devices they are invalid device nodes because we have
> to create them before init starts.  If we don't create them before init
> starts, the following from inittab will be ignored:
>
> vc/3::respawn:/usr/bin/tail -f /var/log/messages
> vc/4::respawn:/usr/bin/tail -f /var/log/syslog
>
> > The current busybox init is not failing gracefully when you do this.
> >
> > That's a sequencing issue.  Whoever wrote this didn't expect the sysinit
> > script to completely redo the contents of /dev.  If I can get it clear in
> > my head exactly what you want to do, I can take a whack at fixing it.
>
> Basically, we use udev.  However, we have to manually create /dev/vc/*
> before init is started because busybox doesn't behave properly if this
> doesn't exist.  What I'd like to see is that we only have to create
> /dev/vc/0 and vc/1, then start init,

This would be the "either" case, above.

> then run udev which will (or not) 
> crate /dev/vc/2-4.  Current bb init doesn't allow this because it will
> ignore the above vc/3|4::respawn statements if those devices don't
> exist _by the time_ init is started.

Technically, it will ignore lines out of inittab that refer to consoles that 
don't exist at the time it reads the line out of inittab.

This is not a new behavior on the part of busybox.

> And init -q doesn't seem to work, so we cannot start with a minimal inittab
> and then add more later and tell init to spawn it.

I think this one's the real problem.  Bug boils down to "init -q doesn't 
work".

There's a major rework of init pending for about the 1.2 timeframe, which kind 
of sapped my personal interest in messing with the current init too much.  
But you need a bug fix before that, so I'll take a look...

I the short term, if you could add an entry in our bug thing 
(http://bugs.busybox.net) about -q not working, it would make sure we don't 
forget this and that you get notified when we fix it.

> > In the short term, there are a few possible workarounds.  You could
> > have your wrapper figure out whether or not it needs to create the
> > device nodes before calling /init.
>
> Yeah, that's what we thought too.  Colin tried to implement this but
> he said our script to figure out whether we're on a serial console
> doesn't work at that point.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list