Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
