Clock init script wait for a few for /dev/rtc but don't give result and fsck (a little) the nice init output (next ebegin start after 10 . ) This check should be "skippable" by /etc/conf.d/clock (i hate to wait ;-) ) Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: I will like to see if it find the /etc/rtc thing :)
Created attachment 66304 [details, diff] Updated /etc/rtc check This patch allows to skip the /dev/rtc checks (if CLOCK_RTC set to no in /etc/conf.d/clock) and get out of the /dev/rtc loop if /dev/rtc is found (a break instead of a bunch of echo)
Created attachment 66305 [details, diff] The "updated" conf.d for clock just added the CLOCK_RTC
so you're saying that the /dev/rtc node is not created in time because you're using udev ?
yap, just get 10 dots and the actual "next" messages arrives after them (the echo is never executed) (And the patched version told me it do not exist at that moment) Not real issue, system pass fine thru, just annoy me to have to wait 10sec for it ;)
FYI: rtc on my system is compiled as a module, and i guess clock is launched before the actual module load...
adding sleeps to init.d scripts is not acceptable what is the module called ?
I agree that adding sleep to init is not acceptable, that why this patch helps to bypass this :-) Look at original baselayout clock script, the sleep are already there, the patch just re-indent them (i could produce a shorter patch, but it then fsck the ident of original file...) in a "configurable" bypass... the rtc module is in ./kernel/drivers/char/rtc.ko But modprobing this one (if exists) just fix a part of the issue, since some people just don't use rtc at all (not in kernel and not in modules...) Or maybe just wipe these "sleep" from the original clock init script ? Anyway, thx for looking at it :)
FYI: http://forums.gentoo.org/viewtopic-t-371047.html
No, udev is _not_ an issue here. By the time this code runs, if the rtc driver is built into the kernel, it will have already created that node. If it hasn't, then the module isn't loaded yet, due to the autoload module stuff happening after the clock start. So, you all can't blame udev this time :)
For the record: I didn't start blaming anyone (cf note #5) Usually, I only start blaming when the "additional comment" count raise over 10 ;) ...
if you update your clock script to do: start() { [ -e /dev/rtc ] || modprobe rtc does it work ?
If you modprobe like that, then yes, you will start having races with waiting for udev to create the device node. I would not recommend doing that at all...
so your only solution is to make the user build rtc support into the kernel ?
Guys, Like i said before, modprobing rtc is not a solution, there are still peoples not using it AT all... and I DO NOT think the current clock init script should made a bunch of sleep...for nothing... Adding RTC to kernel in order to bypass this wait is a little bit "LOL" fixing way... at least it's how i feel... I proposed a simple patch with a configurable skip of this "not-a-real-issue", why the hell do you still wonders about this RTC thing ? Put it on by default if it's SO important, add a notice to the ebuild 'if you use RTC, we suggest you to build it into the kernel and not as a modules, otherwise change the CLOCK_RTC to value "no" to skip the RTC wait" ... Or maybe just default it to no for this check, seems from previous comments that udev will already have done his job, so is actually a point to wait ? Can someone show me a "good" reason to keep it and explain me why the hell the new baselayout should need specific tweak in kernel ? (especially RTC... not really usefull in common installations for me...) Sorry if you feel i am rude, I just want to put things clear, i really appreciate your attention on this "problem", just feel it don't go toward a right solution :) Thx
fyi: same for baselayout-1.12.0_pre7-r1
baselayout-1.12.0_pre8-r2 is buggish, too. latest working version here is: 1.11.13-r1. please fix this bug, it's quite annoying.
As a side note in pre6 setting the time did not work at all (I had local time set). At least in new versions it has been working as far as I can tell.
removed hacks from clock script
