Re: init requires /dev/vc devices
On Sun, Jan 29, 2006 at 12:12:08PM -0600, Rob Landley wrote:
> On Saturday 28 January 2006 19:11, Martin Michlmayr wrote:
> > I'm taking this discussion to the busybox list in the hope that they
> > can help. In debian-installer, we use buxybox. For the 2.6 images,
> > we're not using udev to create devices. However, busybox's init is
> > started before udev and it require some devices, so among others, we
> > create /dev/vc/0 to 4.
>
> You're using devfs names, so I'm guessing you have CONFIG_FEATURE_DEVFS
> enabled.
>
> Which version of busybox are you using?
1.01
> > While this works well on most machines, I get error messages later on
> > because the devices /dev/vc/2..4 don't exist - my device doesn't
> > actually have any virtual terminal, just a serial console. vc 2-3
> > (if available) are used in the installer to display debugging
> > information.
>
> What inittab are you feeding it? (Or are you leaving it to the default one?)
# /etc/inittab
# busybox init configuration for debian-installer
# main rc script
::sysinit:/sbin/debian-installer-startup
# main setup program
::respawn:/sbin/debian-installer
# convenience shell
vc/2::askfirst:/bin/sh
# logging
vc/3::respawn:/usr/bin/tail -f /var/log/messages
vc/4::respawn:/usr/bin/tail -f /var/log/syslog
# Stuff to do before rebooting
::ctrlaltdel:/sbin/shutdown > /dev/null 2>&1
# re-exec init on receipt of SIGHUP/SIGUSR1
::restart:/sbin/init
> > I was wondering whether we could only create /dev/vc/0 and 1, start
> > init and then udev create the rest. But this is too late for init.
> > Even running init -q doesn't help to bring those debugging messages on
> > vc 2-3.
>
> The "::sysinit:/etc/init.d/rcS" line should get run first. You can
> populate /dev from there.
Since we have vc/* entries in inittab, init needs to have those devices
available before it starts or it gets upset.
> (I mention here for completeness that busybox has a new mini-udev called mdev,
> but you probably already knew that, and it produces traditional names rather
> than devfs names. Basically it just copies whatever directory names it finds
> in /sys. I _really_ need to do a properly release announcement, after we get
> 1.1.1 out the door...)
I think it's probably simplest to stick with regular udev in this
application - apart from anything else we have some considerable work to
do to shift over to non-devfs names, and when we finally do shift it
will be good to be using the same udev in the installer as in the
installed system.
> > Below is some more background information. I was wondering if you
> > have any ideas how to handle this situation. IMHO, it should be
> > possible to run "init -q" later on. i.e. we could have an inittab
> > file which'll only reference the first terminal, create that device,
> > start init, have udev create the rest, then add more inittab entries
> > (if the machine has the virtual terminals) and then run init again to
> > re-read inittab. Unfortunately, this doesn't work at the moment.
>
> Re-reading inittab is unfortunately flakier than it should be, but it should
> minimally work. You mentioned a floppy, do you have an image we could try to
> reproduce the failure?
I hope Martin can point you to what he's using; any of the builds on
http://www.debian.org/devel/debian-installer/ should do if booted from a
serial console, but Martin's on MIPS hardware and I don't know if this
reproduces on i386.
> I'd still try calling udev from the sysinit script, which should be before it
> tries to spawn the consoles.
We already do call udev from our sysinit script. Furthermore, we have a
special init shell script that does some setup and then chains to
busybox init; one of the pieces of setup it does is to create
/dev/vc/[0-4], and removing that causes init not to spawn the programs
listed for vc/2, vc/3, and vc/4 in inittab.
This much is easily reproducible with normal hardware, or even in qemu.
Grab http://people.debian.org/~joeyh/d-i/images/daily/netboot/mini.iso,
boot it with 'install BOOT_DEBUG=3', 'nano
/lib/debian-installer/init-udev-devices' and remove the stuff that
creates /dev/vc/*, then 'exit' twice; you should now get the installer
main menu,
> > > Having looked into it a bit, I don't see how this can be caused by the
> > > devices existing. After all, the objection from init is that the devices
> > > *don't* exist! Why is stat() failing on them?
> >
> > The device nodes are there but my device doesn't actually have those
> > _devices_.
>
> Not a lot busybox init can do about your vcs device nodes pointing to
> nonexistent devices.
Our problem is that if we don't create the devices, init fails to spawn
programs when run on hardware with virtual consoles; but if we do create
the devices then apparently it breaks on hardware without virtual
consoles. It's rather fiddly for us to have different inittabs for the
two cases, so some other way to resolve this deadlock would be nice.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: