On a fast system, dbus isn't immediatly ready when other services try to use it. Such cases a usually hit when using parallel startup. In my case hald didn't start. Inserting a "sleep 3" in /etc/init.d/dbus after the line starting the daemon was sufficient to fix this. Without dbus and hald properly starting all sorts of strange problems arise such as mt-daap not working, portmap failing, ypbind timing out... (in my setup) The bootup takes very long because of this (up to 5 minutes) Reproducible: Sometimes Steps to Reproduce: 1. Use baselayout-2 with openrc and parallel startup 2. Given a fast enough system it happens always (hald cannot start) 3. Slower systems hit the problems only sometimes Actual Results: Startup completely fails or takes ages of time with different services failing raising all sorts of strange problems not always reproducable with exact the same results. Expected Results: Flawless startup of course... ;-) Tested on P4-3.2-HT x86, 2 GB RAM, baselayout-2 and openrc-0.2.5, networking done with dhcp and ifplugd.
I'm not seeing this on my Core2 Quad o'ced to 3300Mhz for each core. That machine should be plenty fast enough :) The issue actually sounds like net.lo didn't start or started too late.
please enable rc_logger in /etc/rc.conf, reboot the system, and then post the log file as an attachment
