[BusyBox 0000843]: Busybox init requires tty device files to exist before the sysinit script is run and init -q doesn't work

bugs at busybox.net bugs at busybox.net
Sun May 7 21:17:15 UTC 2006

A NOTE has been added to this issue. 
Reported By:                alemc
Assigned To:                BusyBox
Project:                    BusyBox
Issue ID:                   843
Category:                   Other
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Date Submitted:             04-20-2006 00:03 PDT
Last Modified:              05-07-2006 14:17 PDT
Summary:                    Busybox init requires tty device files to exist
before the sysinit script is run and init -q doesn't work
If the /etc/tty0 - /etc/tty63 files do no exist before inittab is read
(e.g. on init start), init can't use the virtual terminals.  This is a
problem when trying to use a udev only system (i.e. where the tty# files
do not exist until udev is started), when udev is executed from the
::sysinit 'runlevel' (e.g. no /linuxrc, or /linuxrc does the absolute
minimum to boot into init).  The workaround is the have static device
files for these devices, either in the root filesystem or created by
linuxrc for initrd-based systems).

I just found a thread about this here (after I figured it out with a
completely different google search; it seems my googling skills need to


Apparently 'init -q' doesn't work, and even if it did it's not documented
(in busybox.txt generated during busybox build at any rate).

Which concludes with:  

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
> > script to completely redo the contents of /dev.  If I can get it clear
> > 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
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
> 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 

There's a major rework of init pending for about the 1.2 timeframe, which
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
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.


 alemc - 04-20-06 00:06  
I realized this can be worked around, so the severity should probably be
lowered.  It's more critical to debian than for the boot disks I'm

 landley - 05-07-06 14:17  
svn 14606 

Issue History 
Date Modified   Username       Field                    Change               
04-20-06 00:03  alemc          New Issue                                    
04-20-06 00:03  alemc          Status                   new => assigned     
04-20-06 00:03  alemc          Assigned To               => BusyBox         
04-20-06 00:06  alemc          Note Added: 0001309                          
05-07-06 14:17  landley        Note Added: 0001349                          

More information about the busybox-cvs mailing list