BusyBox/inittab weirdness

Rob Landley rob at landley.net
Wed Dec 7 20:09:51 UTC 2005

On Wednesday 07 December 2005 12:06, Rory Vieira wrote:

> The second line, yes. But as I am omitting the whole thing on
> line 1, I don't know where that's pointing to. If I remember
> correctly from the manual, it should be /dev/console (or the
> current active console)

I read the source code pretty throughly when I was doing my init rewrite, but 
I don't know if what I remember is what it was doing or what I changed it to 
do because what it was doing was stupid.

I need to dig that back up, or redo it.

> > > The first line shows 'echo' and 'uname' without a path
> > specification.
> >
> > Did you give an absolute path to either one?
> Nope.

Ok, so when you specify a path in inittab, init shows this path.  When you 
don't specify a path in inittab, init doesn't show a path.

Where's the problem again?

> > > Obviously I needed to make the 'mount', 'sh', and 'init' links
> > > beforehand. Why do I need to do this for mount etc, but not
> >
> > with echo
> >
> > > or uname?
> >
> > Why did you specify an absolute path for them, but not for
> > echo and uname?
> Well, that's what I'm trying to find out *grin*

You made the inittab file...

> > > If I change the second line to just 'mount...' it claims it
> >
> > can find mount at all...
> >
> > I have no idea what your $PATH is set to.
> Well, as it is inittab we're talking about... I assume nothing or
> /bin:/sbin. I really don't know as I haven't set a path yet...

If $PATH is blank, bash will suppose some deeply stupid defaults that, 
strangely enough, gcc refuses to work with.


The default path provided by bash (2.05b, anyway), if PATH is unset when you 
run bash, is:

Note the "." at the end of the path.  If the current directory is in the path 
anywhere, the gcc component "collect2" will refuse to search the $PATH when 
looking for "ld", and will thus generally ever find it.  It doesn't explain 
_why_ it can't find ld, it just decides it knows better than the user and 
silently skips searching the path based on a dislike of one of its 
components.  There is no error message, other than "can't find ld".  The fix 
is simply:
  export PATH=/bin:/sbin:/usr/bin:/usr/sbin
But finding that _out_ involves spending an evening tracing your way through 
gcc and collect2.

And you wonder why my opinion of the Free Software Foundation's code is 
something less than abject worship?

> The line '::sysinit:echo...' is in fact the first line. I'm setting
> the path in /etc/rc.d/rcS but that is still a few lines lower in my
> inittab.
> In this case I think the obvious question would be:
>   What is BusyBox' default path setting?

Let's see, busybox has libbb/setup_environment.c with DEFAULT_LOGIN_PATH and 
DEFAULT_ROOT_LOGIN_PATH.  So naturally, with such a clean mechanism in place, 
the various applets which merely have "busybox" painted on the side don't use 
it.  Things like udhcp, ifupdown, and ash all set their own path from a 
hardwired list.  (Largely the same list, actually, but separate copies 

init/init.c also ignores busybox's mechanism, but it at least uses 
_PATH_STDPATH, which is some kind of standard I vaguely remember looking up a 
year and change ago when I was poking init.  It's posix or some such, and I 
believe it's in your system header files.

> PS I read that whole thread about the tar/cpio thing. It was extremely
> interesting to read (even for my level). Now somewhere I read the line
> about how to use cpio to 'extract' the archive. Any chance you know
> how to create it using cpio?

Um, I've done it, but not recently.

You can more or less reverse the cpio extract line I gave.  if you can't get 
it to work poke me and I'll take a whack at it, but giving you a divinitive 
answer involves putting together a quick little "hello world" style initramfs 
directory, making the cpio.gz, copying that file into the linux build, and 
actually testing that it does indeed boot properly with that.

Thats a good 15 to 20 minutes of work, and most of it involves reading the man 
pages and trying out what they say.  I usually just let the kernel build the 
sucker for me anyway, since that's so easy.  (Just point the initramfs 
generator at a directory and it'll  build the cpio archive from that.  No 
need to use an archiver when there's one built into the kernel 

> I'm actually thinking of giving initramfs 
> a try. Until now I have created static images that were initrd's. I've
> even got as far as to utilize the pivot_root/chroot stuff and got it
> working too.

With initramfs you have to use switch_root, for reasons I explained in the 
initramfs docs I sent the kernel guys (It's in 2.6.15-rc1 and up).

> But it's a pain in the neck, and hard to understand for 
> that matter... I have the idea (or it least hope so) that initramfs is
> more suitable for my needs.

It's pretty cool.  Feel free to ask me questions and I'll try to answer them, 
but read the docs first.

> Now my mini initrd simply created a tmpfs, which I fill by extracting a
> tar file from cd, and pivot to it, so I can clear the memory used by the
> initrd. I hope this whole step will not be nessesary at all...

Yup.  It's generally pretty straightforward.

My firmware-linux build is already doing this, by the way.  
"http://www.landley.net/code/firmware".  I'd hoped to get a new version up 
this past weekend, but haven't yet due to spiky design issues that aren't 
responding well to being glossed over.  Currently aiming for tonight... :)

> Cheers,
> Rory

Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

More information about the busybox mailing list