I built a kernel and initramfs for a pre-release 2.6.26 kernel, and it failed to boot. I entered the shell, and an `ls /dev/` reported very few devices - none of the ones normally autocreated by mdev, just /dev/null, /dev/console, and the other nodes built into the image. I recompiled several times, thinking it was a driver conflict, before giving my forehead a whack and thinking "Why don't I just try running `mdev -s`?" So I did, and it reported this: mdev: /sys/block/: No such file or directory mdev: /sys/class/: No such file or directory "Aha!" I thought, "/sys/ is unmounted!" So I ran `mount -t sysfs sysfs /sys/`, re-ran `mdev -s`, and there were my device nodes! Then, I grepped for sysfs in /linuxrc and /etc/initrd.scripts, and came across this gem: 207: mount -t sysfs /sys /sys >/dev/null 2>&1 Might this be fixed in an -r2?
Care to tell us what's actually wrong with that command? It's certainly worked fine up until now.
Hm. Your comment made me curious, so I added an echo to that line - apparently, it never gets called at all. My mistake in diagnosing, it seems. I'll add some more echo commands to see why it doesn't get called.
If you can figure out what caused this, please reopen and provide more info. In the mean time, I removed the check that it's a kernel >=2.6, which *might* have been causing the problem for some reason. Now, sysfs should be mounted pretty much unconditionally.
Your surmise is correct - sorry I didn't post here, but I did find that while the uname command to find the kernel version works correctly when stdout = terminal, the backtick expression stores an empty string in the variable. Setting it to unconditionally reteurn that it was a 2.6 kernel solved that problem, but then it refused to trigger the startLUKS function for some reason, despite being passed the crypt_root=/dev/sda2 parameter. Capitalizing (CRYPT_ROOT=/dev/sda2) solved that for some reason, but it still does not not run the startVolumes function (even if I capitalize real_root) Entering the shell and running evms_activate works fine, however, so I've been doing that, hitting ^D, and specifying /dev/evms/DataRoot. Part of the reason I didn't post was because I think this may be caused by me using a newer version of busybox because the one that genkernel specifies fails to build.
There is an issue when building busybox statically. In my tests, it led to exactly the behavior you describe (backtick expressions ending up empty). With your newer busybox version, our patch to fix that issue no longer applies. Instead of upgrading busybox for genkernel, perhaps you can post your build errors for busybox-1.7.4. This is the first we've heard of any build errors.
(In reply to comment #5) > There is an issue when building busybox statically. In my tests, it led to > exactly the behavior you describe (backtick expressions ending up empty). Yes, static sys-apps/busybox-1.8.2 is broken. $ echo "a:b" | busybox cut -d : -f 1 | wc -l 0 $ echo "a:b" | cut -d : -f 1 | wc -l 1 $ Seems, http://sources.redhat.com/bugzilla/show_bug.cgi?id=3400 strikes back.
If you're going to use a version of busybox other than what comes with genkernel, please know what you're doing. It's not our problem.
