[BusyBox] suddenly, busybox init process is failing spectacularly
Tito
farmatito at tiscali.it
Sat Feb 21 21:46:23 UTC 2004
On Saturday 21 February 2004 14:26, Robert P. J. Day wrote:
> after having built and successfully downloaded and booted a
> busybox-based system for a target board, i went in and tweaked what i
> thought were some minor config options in BB, and suddenly the boot
> process was failing miserably. after backing off to what should have been
> a working configuration from the CVS repository, it's *still* failing, and
> i've spent the last three hours trying to track down the problem.
>
> currently, i have busybox emulating "init", with a fairly simple
> /etc/inittab file:
> -----------------------------
>
> ::sysinit:/etc/rc.sh
>
> tts/0::respawn:-/bin/sh
Hi,
tts/0 = ttyS0 ?
From the man:
If you choose to use an /etc/inittab file, the inittab entry format is as follows:
<id>:<runlevels>:<action>:<process>
<id>:
WARNING: This field has a non-traditional meaning for BusyBox init!
The id field is used by BusyBox init to specify the controlling tty for
the specified process to run on. The contents of this field are
appended to "/dev/" and used as-is. There is no need for this field to
be unique, although if it isn't you may have strange results. If this
field is left blank, the controlling tty is set to the console. Also
note that if BusyBox detects that a serial console is in use, then only
entries whose controlling tty is either the serial console or /dev/null
will be run. BusyBox init does nothing with utmp. We don't need no
stinkin' utmp.
Hope this helps.
Ciao
Tito
> #::respawn:/usr/sbin/xinetd -stayalive -reuse -pidfile /tmp/xinetd.pid
> #::respawn:/bin/application
> -----------------------------
>
> while /etc/rc.sh starts with:
> -----------------------------
> #!/bin/sh
>
> # Configure local networking.
>
> echo "Configuring localhost networking ..."
> /sbin/ifconfig lo 127.0.0.1
>
> # Clear the mount table.
>
> echo "Clearing mount table in /etc/mtab ..."
>
> >/etc/mtab
>
> # Mount the /proc filesystem.
>
> echo "Mounting /proc filesystem ..."
> /bin/mount -t proc proc /proc
>
> ... and a bunch of other stuff, snipped for brevity.
> --------------------------------
>
> until now, this has been working wonderfully. then, after my tweaks, i
> downloaded the ramdisk image, whereupon the boot produced:
>
> -----------------------------------------
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 1110k freed
> VFS: Mounted root (ext2 filesystem).
> Mounted devfs on /dev
> Freeing unused kernel memory: 60k init
> Bumme <---- ??????????????????????????????????????
> Please press Enter to activate this console.
>
>
> BusyBox v1.00-pre7 (2004.02.21-11:53+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> -sh: can't access tty; job control turned off
> -----------------------------------------
>
> normally, at this point, i expect to see INIT start up and start running
> everything in /etc/rc.sh. instead, i get the chopped off string "Bumme"
> and nothing being run out of /etc/inittab, apparently. (annoyingly,
> minicom insists on chopping off that error string, which is unfortunate
> since i assume seeing the whole thing might have been informative. more
> on that shortly.)
>
> i have no idea why init suddenly stopped running. it's clearly selected
> in the BB configuration. in an effort to figure out what the rest of that
> "Bumme" message might have been, i finally resorted to tracking down
> *every* location in the BB-1.00-pre7 code that printed a message starting
> with that, and added a unique character to the beginning. most of those
> were in init.c, and one in syslogd.c. (can you tell i'm getting
> desperate?)
>
> i rebuilt BB, actually ran "strings" on the executable, verified that
> all of those strings had a unique character at the beginning, rebuilt my
> downloadable ramdisk, downloaded and booted to get:
>
> Mounted devfs on /dev
> Freeing unused kernel memory: 60k init
> Bumme <--- argh!! where is this coming from?
> Please press Enter to activate this console.
>
> at this point, i'm kind of beside myself with frustration. for those
> who are familiar with the boot procedure, once the kernel gets past the
> mount of devfs and freeing unused kernel memory, what would you expect
> to see? from memory, i was sure that that was where init kicked in.
> so where could that message be coming from?
>
> i'm definitely open to suggestions.
>
> rday
>
> p.s. once i get a console, if i run "mount", i get the error message
>
> # mount
> mount: /proc/mounts: No such file or directory
>
> but i can manually mount that with
>
> # mount -t proc proc /proc
>
> and manually do the rest of what's in /etc/rc.sh. so, clearly, init isn't
> doing any of that at boot time. what could be causing init to simply not
> run properly? this worked so nicely for the last couple of days.
More information about the busybox
mailing list