Help entry for makedevs?

Rob Landley rob at landley.net
Sun Jan 15 03:18:46 UTC 2006


On Saturday 14 January 2006 17:25, Eric Spakman wrote:
> Hello Rob,
>
> <snip>
>
> >> chmod:
> >> fd/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4/4
> >> /4/
> >> 4/4/4/2: Too many levels of symbolic links
>
> Ok, thanks!
> For the record, the following symlinks are created in the /dev directory:
> ln -sf /proc/self/fd fd >null 2>&1

Let me guess: chown opens a filehandle to /proc/self/fd in order to list its 
contents, and thus /proc/self/fd/4 shows up as a symlink to /proc/self/fd...

You definitely do _not_ want to follow symlinks in this case.

> >> An other corner case:
> >> When you do something like this:
> >> mount -nt proc /proc /proc mount -t tmpfs /dev/root /tmpfs -o size=6M
> >> umount /proc <copy files to the new tmpfs root>
> >> pivot_root . <new root>
> >
> > So you're using 2.4, then?  Or an initrd under 2.6?
>
> I'm using kernel 2.4.32.

It sounds like an idiosyncrasy of /proc, actually.

> >> mount -t proc /proc /proc
> >>
> >> The output of mount is "(null) on / type tmpfs (rw)" instead of
> >> "/dev/root
> >> on / type tmpfs (rw)". It looks like some information is lost after
> >> umounting /proc.

If you're not using /etc/mtab then umounting /proc makes /proc/mounts go away.  
(If you are using mtab, and you chroot, you're screwed anyway.)

> > Actually it's looking like the attempt to lookup /dev/root is failing.
> > We've
> > got code in there (find_block_device() in libbb) that attempts to
> > determine which /dev entry tmpfs should belong to, and if your current
> > /dev is empty it
> > won't find anything.
>
> At that point (before the tmpfs mount) the /dev directory isn't empty, all
> the block devices are available.

I'd have to look at your setup, I'm not keeping yoru context in my head 
between messages and too much goes away in the quote chopping.  (It still 
looks like the lookup of /dev/root is failing.  Why I'd have to look at the 
context to understand.  I still think doing the lookup is the wrong thing.)

> > We've had other reports of that being wonky with regards to df, and it's
> > dog slow anyway.  I need to figure out what all that mess _should_ be
> > doing.
>
> Correct, the output of df doesn't show /dev/root either.

Same failure.

> > I suspect that the correct approach is to rip find_block_device() out
> > entirely and instead modify mdev to create a /dev/root symlink pointing
> > to the correct device based on an examination of /sys.  That way if you
> > want to know where /dev/root lives, you look at /dev/root to see where
> > the symlink points, and we don't try to play silly games based on magic
> > names the kernel is feeding us at runtime.
>
> If I understand you correctly, this approach will only work with kernel
> 2.6?

We could have the /dev/root lookup code invokable to create the symlink at 
boot time, if you care.  (Or you could do it yourself as part of your system 
configuration.  It's really a cosmetic issue, either way.  We have a 
heuristic that attempts to figure it out, but it's not currently reliable and 
seems to do more harm than good sometimes.)

> > Again, I'll play with that this evening if I get a chance.
>
> Thanks again!
>
> > Rob

I didn't get much of a chance, but oh well.  It's a todo item...

Rob
-- 
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