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)
-----BEGIN PGP SIGNED MESSAGE-----
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)
Cheers,
Daniel
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.
======================================================================
http://busybox.net/bugs/view.php?id=843
======================================================================
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
Description:
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
improve):
http://lists.debian.org/debian-boot/2006/02/msg00562.html
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
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.
======================================================================
- ----------------------------------------------------------------------
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
creating.
- ----------------------------------------------------------------------
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
======================================================================
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEXoLUhvWBpdQuHxwRAtq5AJ9FUE1DKCz3CV9NtzHHtPMiA5HjkwCcC552
ybDIlIMYAt1rtTvovu0zwNI=
=1oTS
-----END PGP SIGNATURE-----
Reply to: