Description of problem: On host with multiple RTCs (such as an ARM SoC) where only one of the RTCs is meant to be the "real", battery-backed clock, 88-clock.rules also syncs the clock with the "other" RTCs (which get reset to 1970 on every power cycle). Version-Release number of selected component (if applicable): Seen on 9.20.2 How reproducible: Always Steps to Reproduce: 1.Get an XO-1.75 2.Boot 3.Observe the output of date; hwclock -f /dev/rtc0 ; hwclock -f /dev/rtc1 ; dmesg | grep rtc Actual results: In dmesg, we can see that the kernel is setting system time to rtc1 early and correctly. udev does correctly not call hwclock --hctosys it when it sees rtc1 (because the hctosys attribute is 1), but it /does/ call it when rtc0 appears. So date returns 1970. Expected results: During init, if _any_ rtc has an hctosys attrib, and is set to 1, no further hctosys should be invoked. Additional info: Filing this for informational purposes. Not expecting a fix. This is being worked around in OLPC builds with an override rule file. See http://dev.laptop.org/ticket/11400 BTW, systemd seems to have rtc0 hardcoded :-)
OK, closing as WONTFIX for F-14.