I upgraded to openrc-0.5.1 from 0.4.3-r4 (I think, possibly -r3, which is what was loaded when I last refreshed my backup root partition). I've been running baselayout-2 and openrc-0.x with few issues for some time, tho of course there were some earlier in the development cycle. After doing the etc-update, I rebooted. It hung quite early in the init, trying to load udev, so before anything (well, any non-virtual fs) was mounted read/write (magic-SRQ SUB doesn't show disk activity on the S and U steps). Rebooting to the root backup (still running openrc-0.4.3-r3), I did some troubleshooting. I'm running udev-146-r1 so using emerge --root= pointed at the normal root, I tried something earlier there, udev-145-r1. No change. I tried rebooting with an earlier kernel (I'm running 2.6.32-rc3-337-gbd38193 ATM, that's a direct git kernel, updated yesterday, IIRC), 2.6.30. No change. I checked the udev initscript, and there was no change between versions there, same exact script, so that shouldn't be it. I tried "set -v -x" in the udev initscript to get some debug output. NOW I was getting somewhere! It was hanging on the "start-stop-daemon --start --exec /sbin/udevd -- --daemon" line! So I changed that line, adding --debug to the end. udevd is indeed starting, but apparently, start-stop-daemon keeps waiting for it. Again, it's not udevd itself as I tried changing that and it didn't work, plus the current version works with the old openrc-0.4.3-rX. Next up was reverting to openrc-0.4.3-r4. I'm now back up and running on it. So there's something wrong with the new rc, in its start-stop-daemon personality. It handles udevd differently, and apparently never detects udevd's daemonizing itself, thus, doesn't return. Meanwhile, if I let it go, devfs (confusing name, BTW, given the former meaning of devfs, threw me for a loop wondering why in the world /that/ was trying to run, until I looked at the initscript and decided it had nothing to do with the kernel 2.4 devfs) says waiting for udev, 50 seconds... eventually timing out. It starts and loads a couple more fs (/dev/pts and something else), and then the boot stalls again. If I wait long enough (or possibly if I hit the right key combo), it eventually continues, and most of the system is loaded, thru the boot runlevel and into init3, but it again hangs shortly before I'd reach a login. Either it never gets past that hang, or I didn't wait long enough. But at that point, Ctrl-Alt-Del works to shut down the system properly and reboot once again. Given that noone else is reporting similar, yet, I'm guessing it may have to do with my CFLAGS or some such. I've not yet tested a recompile with conservative values, but I will. I'll attach my emerge --info momentarily, but here's an abbreviated version. udev, openrc and kernel versions mentioned above. arch is amd64, profile 2008.0 no-multilib. gcc-4.4.1, glibc 2.10.1-r0. CFLAGS="-march=opteron-sse3 -pipe -O2 -frename-registers -fweb -fmerge-all-constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -freorder-blocks-and-partition -combine" LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"
Created attachment 206710 [details] emerge --info
what's your rc_start_wait ?? see this one i caught https://bugs.gentoo.org/show_bug.cgi?id=288495
It's not CFLAGS or LDFLAGS. I'm going to test to see if it's bug #288495 as my wait is 200 (should-be ms, actually seconds if it's that bug) and dupe it that way if so, since it's a better description in that case. The only other thing I can think of at this point is that my root is kernel/mdp RAID-6, assembled by the kernel itself from command line parameters passed from grub (no initramfs). I also run lvm2, but not on root, so it shouldn't be a factor at all this early in the boot sequence. But I'm guessing it's the ms/second mixup of bug 288495. Off to check that now.
Sure enough. It's the rc_start_wait timeout of bug 288495. Marking dup. Increasing the effective value by 1000-fold without notice wasn't funny, but of course bugs like that are part of the "excitement" of ~arch! *** This bug has been marked as a duplicate of bug 288495 ***
