May 1, 2011 12:12:01 AM, neal.p.murphy wrote. Hi Neil,
Thank you very much for your comments. I'm trying to comment on your comments now. Alex said: '/lib/udev/rules.d/50-udev-default.rules': SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc" FWIW, I don't see the relevance of rule 50-udev Neil said: The rule in 50-udev creates the symlink '/dev/rtc' to the actual node '/dev/rtc0'. It isn't relevant to the clock being set or not being set. Alex is saying: 1. On all my queries, there's NO 'SUBSYSTEM=="rtc"'. To reinforce to the readers (in case they missed it), I had asked, " What is a possible configuration that would trigger the _SUBSYSTEM_ action in 55-lfs (2) ?" Neil answered: *As written*, the subsystem rule is triggered *if* the RTC is in subsystem rtc; if there is no such subsystem, the rule will never be triggered. The kernel rule will never be triggered because it is looking for a device with kernel name 'rtc'; this device doesn't exist. If this rule is changed to look for a device with correct kernel name of 'rtc0', it will be triggered. Alex is saying: What rtc0 are we talking about? As a reminder to the readers (in case they missed it), I had written, ls -l /dev/rtc* crw-r--r-- 1 root root 10, 135 2011-04-30 20:32 /dev/rtc [please note the star above] Alex said: I'm still puzzled about not being able to find any traces on the console about 'setclock' being run by udev (55-lfs above). Is it possible that "inside" udevd the standard message "Setting system clock..." goes somewhere else? The log-fog? Neil answered: The log level may be set to, or default to, 'err'. If you change it via udevadm control --log-priority=info or udevadm control --log-priority=debug you should see all the info you're looking for--'debug' will show a *ton* of info. Alex is saying: 1. I'm not so sure. You're suggestion works only during a live system to change log levels dynamically (as they say). Would work like when you through another clock (like a grandfather's) at the machine and you want to see how udevd reacts in detail :) Our case (whether setclock script is run by Udev on start-up or not) is obviously a booting situation par excellence. You prepare for it _before_ reboot by "statically" setting the _following_ udevd log-level in '/etc/udev/udev.conf' (from say, default "err" to "debug"). 2. That said, there's NO trace (so to speak) of a "setclock" run what so ever (as they type now a days) in the debug-log. OTOH, I have now positive proof that udev _does_ run setclock on start-up. That's a 360 (as they say) reversal of what I said in my previous post. Rest assured, the crow has already been boiled, enjoyed and the green remains ecologically disposed of. Alex, on departing, is raising some new questions: Based on already (twice) mentioned ls -l /dev/rtc* crw-r--r-- 1 root root 10, 135 2011-04-30 20:32 /dev/rtc, I'm speculating that the difference between me and the rest of users (see also Simon's previous post of May 2, 2011 04:19:34 AM) who can proudly display a "/dev/rtc0 (with a /dev/rtc symlink)" or some such, is that I have CONFIG_RTC set to <M> as opposed to [Y] :( Questions: 1. Can this be true (a well known fact to everybody else)? (I know, I know, recompile the kernel with [Y] and see what happens :) As a matter of principle, I've always favored kernel/Udev to decide for me what module(s) is needed and when. 2. Normally, the kernel configuration has been careful to make a distinction between [Y/N] and [Y/M/N] depending on the situation. Is this a mis-coordination between Kernel and Udev, and the RTC _must_ be either Y or N (i.e., no M)? All I can certify is that my machines, always with <M>, have worked very smoothly (RTC-wise) all these years. I've never ever missed a /dev/rtc17 or the symlink. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
