[gentoo-amd64] having trouble running root off raid

[gentoo-amd64] having trouble running root off raid

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, I've been steadily migrating all my data to a raid array.  I have
everything running under raid5+lvm2, except for my root partition, which
is 1GB and running raid1 (no lvm).

On the root partition are:

bin, sbin, lib32, lib64, root, etc

I think that should be all that is needed to boot the system and mount
/usr, /var, and everything else.  Actually, I know it is, since I can
boot just fine with only those directories actually on my old root.

The system boots just fine with the root partition on a non-md device
(my old root).  When I try to boot with root=/dev/md2, however, I get a
panic right after the freeing memory message.  The error is unable to
open initial console.  I was wondering if for some reason it couldn't
find init, so I explicitly stated init=/sbin/init - no effect.  Then I
tried setting init=/bin/bash to see if I could at least get a shell -
that gave me a not syncing (attempted to kill init) panic.

Am I missing something obvious?  I do see on the console that it is
building the /dev/md2 array.  Also, I get the "VFS: Mounted root (ext3
filesystem) readonly." message, so it obviously is looking at the root
filesystem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhwxaG4/rWKZmVWkRAlhPAKCkL5DwqLXKYEu1Y3501E9KgdiF+wCeOrG3
EP+wXjLm30HyVYh7ceK5t08=
=hkvO
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

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

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Freeman wrote:
> Am I missing something obvious?  

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.

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

Oh, and line 329 of /sbin/rc calls clear, which is in /usr/bin.  Not
that it causes much trouble...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhxd0G4/rWKZmVWkRApR5AJwNNch/bgvokUIuC88OxrHk3PD0CgCfQJs5
OVAd8HJOCoTaksoqioSPTHQ=
=zI7y
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

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

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Freeman wrote:
> 
> 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...
> 

Hmm - it looks like the key is to spam the list after banging your head
against the wall in frustration - 10 minutes after sending the email to
the list I figured it out...

It turns out that the rc-scripts aren't nearly as smart as the linker,
and that symlink from /lib to /lib64 is pretty important...

As far as I can tell I'm up and running with my root on raid!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhxqYG4/rWKZmVWkRAlsmAJ4/o/Ca7aQWqKm7TBFiYu2q60vviwCfUE3y
GDLJu1UpK+2DxSusXhqeF0o=
=tRND
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

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

[Duncan]

Richard Freeman <rich@thefreemanclan.net> posted
46871776.7020704@thefreemanclan.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@gentoo.org mailing list