BusyBox/inittab weirdness

[Rob Landley]

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.

details:

The default path provided by bash (2.05b, anyway), if PATH is unset when you 
run bash, is:
   /usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:.

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 
thereof.)

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 
compilation...)

> 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

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