[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A note on busybox bugfix: (Fw: [BusyBox 0000843]: Busybox init requires tty device files to exist before the sysinit script is run and init -q doesn't work)

Hash: SHA1

The problem with busybox not recognizing tty's not present as devices
before busybox init is run has been fixed (or rather init -q works)



Begin forwarded message:

Date: Sun, 7 May 2006 14:17:14 -0700
From: bugs@busybox.net
To: alemc.2@bmts.com
Subject: [BusyBox 0000843]: Busybox init requires tty device files to
exist before the sysinit script is run and init -q doesn't work

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@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 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

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
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:

- -- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore

Version: GnuPG v1.4.1 (GNU/Linux)


Reply to: