On Wed, Aug 3, 2011 at 11:09, Matthew Burgess <matthew@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 3 Aug 2011 01:38:45 +0200, Kay Sievers <kay.sievers@xxxxxxxx> wrote: >> On Wed, Aug 3, 2011 at 00:01, Matthew Burgess <matthew@xxxxxxxxxxxxxxxxxxxx> wrote: > # This causes the system clock to be set as soon as /dev/rtc becomes available. > SUBSYSTEM=="rtc", ACTION=="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start" > KERNEL=="rtc", ACTION=="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start" > I have a suspicion that the rtc rule could fail if a user had /var as a separate > partition, and /dev/rtc was created before the /var partition had been mounted > (the setclock script calls out to hwclock, which requires /var/lib/hwclock/adjtime). > Our initscripts in question are S10udev and S40mountfs, so I guess this is > theoretically possible. > > Do you agree with the above analysis, and if so what do I need to do to fix this? That's all fragile. My take is that userspace should not fiddle with the rtc clock at all. The kernel itself syncs properly with the rtc, long before userspace even runs, which is the only sensible thing to do, you don't want random jumps in system time. Userspace has no idea what the correct time is until ntp runs anyway. There is only one 'broken' setup that needs some adjusting, and that is rtc in localtime. That should ideally be fixed by configuring Windows to run the rtc in UTC, which works totally fine these days If you really want to support that localtime crap, just adjust the timezone in the kernel, but don't fiddle with broken adjtime, hwclock or anything else. If anyone wants proper time, he needs ntp, not some wild guessing by tools, that have no idea what the actual time really is. What distros did here in the past is not convincing at all. This is what systemd does: http://cgit.freedesktop.org/systemd/commit/?id=7948c4dfbea73ac21250b588089039aa17a90386 http://cgit.freedesktop.org/systemd/commit/?id=da2617378523e007ec0c6efe99d0cebb2be994e1 and it will never touch the clock but supports rtc in localtime. Running adjtime or hwclock and rtc in localtime will break all sorts of setups like live-cds, and so on. > I could just remove the RUN+= from the rtc rule, and have setclock be an initscript > that starts after S40mountfs. I think we used to have things configured this way, but > moved to the RUN+= method a while ago. > > Aside from that issue, is there a way to ask udev to print all failed events, as opposed > to retrying them. As LFS is a fairly minimal system, I'm concerned that users may end up > creating or installing bootscripts that have similar issues, so having a way of printing > failed events would be a useful first step in diagnosing their issues. No, the entire tracking of failed events will be removed. And no events are marked as to-be-tracked by default, so there is nothing to print usually. If you have marked events, you can run 'trigger --type=failed -n -v' and it will print what it would do. But it is not used today for anything useful, and don't rely on that in the future, it will go away. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
