[gentoo-amd64] Re: having trouble running root off raid

[Duncan]

Richard Freeman <rich@××××××××××××××.net> posted
46871776.7020704@××××××××××××××.net, excerpted below, on  Sat, 30 Jun 2007
22:54:46 -0400:

> It turns out it wasn't obvious, but I was missing all my device nodes in
> /dev.  Apparently even with udev you need some stuff in there to get
> started.

OK, I see you've got it all working now, but FWIW...

Yes, there two specific device nodes that Gentoo's initscripts need 
before udev is setup.  However, with a newer baselayout, it should work 
without them, you'll just not be able to see if anything's going wrong in 
that section since there's no /dev/console to write to. (/dev/null is the 
other required device node.)  Actually, that's probably what was going 
on... the problem below (udev not loading) wasn't showing up, because 
there wasn't a /dev/console to write the error to.

So... sounds like you put all your device nodes in the rootfs /dev.  You 
can leave it that way if you wish, or remove all the devices except for 
/dev/console and /dev/null.  That's the way I'm running here, just those 
two on the rootfs.

For the official word, see the Gentoo udev guide.  It's listed in the big 
Gentoo docs list, here:  http://www.gentoo.org/doc/en/list.xml .

> However, I'm still getting stuck.  Now I get an error from rc telling me
> that the system doesn't support UDEV.  I'm using the EXACT same kernel
> as the one that works fine on a different root.  Not quite sure what the
> problem is...

I see from your later reply that it was a missing /lib -> /lib64 
symlink.  Yes, that's required.  /lib64 has the 64-bit libraries in it, 
but /lib contains way more than just binary libraries.  Among other 
things, it's also the traditional location for non-binary system utility 
scripts.  Those designed to be run directly by the user/sysadmin are 
generally in /bin and /sbin (and of course the initscripts in /etc/
init.d, symlinked in /etc/runlevels), while those normally only called by 
other scripts, not designed to be run directly, are normally located in /
lib.  Since they aren't actually binaries, they are bitness and arch 
neutral, and are thus normally located in /lib, regardless of the arch.

FWIW, I ran into this one myself when I switched from multilib to 64-bit 
only.  I tried running separate /lib and /lib64 dirs, no symlink.  If it 
worked perfectly as explained above, that should have worked.  However, 
there's at least one place in baselayout where something placed 
specifically in lib64 by the package installation, is then invoked 
specifically from lib (not 64).  Strictly speaking, that's broken, since 
the path should be consistent, one or the other, not placed in one and 
then invoked as if it's in the other, but I wasn't worried about it 
enough to file a bug on it.  I just moved everything from lib back under 
lib64, and recreated the symlink.

> Oh, and line 329 of /sbin/rc calls clear, which is in /usr/bin.  Not
> that it causes much trouble...

Now /that's/ something that should be bugged.  There's a decently strict 
policy not to put stuff in /usr that's needed before /usr may be mounted, 
since it's relatively common to have /usr on a separate partition.  This 
breaks that policy, so it should be bugged.  They need to either avoid 
using clear, or move clear to /bin.  (If there are packages that call it 
using the absolute /usr/bin/clear, place a symlink -> /bin/clear there.  
That's not a problem.  What /is/ a problem is calling it from a script 
that's run before /usr may be mounted.  In this case it's not fatal, but 
it's a policy issue that needs corrected none-the-less.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list