Again, the reverse of http://bugs.gentoo.org/show_bug.cgi?id=68133 On a kernel with it compiled as a module, the rtc module (and therefore /dev/rtc on a UDEV system) will normally be loaded by /etc/init.d/modules, using the entry as it appears in /etc/modules.autoload.d/kernel-2.6. Of course as already noted in clock bug family <g> referenced above, even if rtc is compiled into the kernel and the /dev/rtc node is available for use immediately after checkroot (where it is located now), /etc/localtime symlinks /usr/share/zoneinfo/??, which may not be available if localmount hasn't yet run, and localmount may of course depend on fs and hardware modules loaded by the modules script. That's fine and everything works **IF** the NEED localmount dependency in /etc/init.d/clock is properly observed, since localmount needs checkfs, which needs modules, ensuring both the modules and /usr/share/zoneinfo/ are available. Unfortunately... The $CRITICAL_SERVICES string in /sbin/rc and related critical services start loop don't honor dependencies written into the init-scripts themselves! The loop simply processes the scripts in the order listed in $CRITICAL_SERVICES, **FLAT-OUT** **IGNORING** dependencies listed in the scripts for VERY VALID REASONS (the scripts might break if those dependencies aren't honored -- NOT GOOD for "CRITICAL" scripts!). Of course, I can see there's a reason the order was switched based on bug #68133. However, if the script dependencies were honored as they should be, switching the order in the variable wouldn't have made a difference, and perhaps the person doing that switch would have stopped to think just WHY the dependencies were there, before simply removing them. Thus, what we have here is sort of two bugs, or a root-bug and its immediately visible more critical symptom. The root-bug is that dependency information is now currently stored in two spots, the scripts themselves, and for critical services, the order of the critical listing. The in-service-script location is well documented in even the basic Gentoo Handbook documentation, and should be enforced. The second, that of the $CRITICAL_SERVICES var in the /sbin/rc script itself, isn't documented at all (to my knowledge), and should be removed to prevent "undocumented features" like the out-of-dependency-order startup of critical services, if they happen to be listed in a different order in $CRITICAL_SERVICES. Of course, fixing the root bug may not be quite trivial. Fixing the immediate issue of clock failing because its upstream dependencies aren't yet loaded should be much easier, altho fixing both this immediate issue AND its reverse in 68133, might be rather less trivial. Reproducible: Always Steps to Reproduce: 1a. Have rtc compiled as a kernel module. OR 1b. Have /usr/share/zoneinfo/ on a non-root-fs, possibly needing its OWN module. 2. Emerge baselayout-1.11.5. 3. Ensure there is no /etc/runlevels/${BOOTLEVEL}/.critical with appropriate initscript ordering. 4. Reboot. Actual Results: Needed modules, device nodes, and filesystems aren't yet available, so /etc/init.d/clock FAILs. Expected Results: /sbin/rc's $CRITICAL_SERVICES and the alternate /etc/runlevels/${BOOTLEVEL}/.critical should be processed using standard initscript dependency ordering, regardless of the order as listed in the file/var. /etc/init.d/clock should have successfully synced the system clock with the hwclock. emerge info to be attached. Specifically: * kernel 2.6.10-rc1 from kernel.org, rtc.ko as module. * baselayout-1.11.5. * a separately localmount-ed /usr Marked "Major" because seeing a red status during boot is "major" to me, particularly with it being a "critical service" that's failing (even if in my particular case ntp-client/ntpd generally fix the clock error, and it can be avoided all together with a properly tweaked .critical ). After that's fixed, I'd suggest remarking severity as normal/minor/enhancement until in-script dependencies are properly honored. (I'd call it normal after the clock is fixed, but wouldn't quibble with minor/enhancement and seeing the dependency aspect put off until 1.12 or whatever.)
Created attachment 43267 [details] emerge info output
clock moved to the end of the critical services list (after localmount/modules) as for the critical services ignoring dependencies, the simple flat loop is done on purpose atm ... ive filed Bug 70009 to handle that since this bug is only about clock starting too early
Wow! That was FAST! =:^)
