Red Hat Bugzilla – Bug 569335
dracut doesn't know whether hwclock is utc or localtime
Last modified: 2010-03-25 18:39:49 EDT
Description of problem: During the boot process dracut doesn't appear to know whether the hardware clock is set for utc or local time. Although the root filesystem has a /etc/sysconfig/clock containing this information, during the boot process this is not known, and the assumption is always made that the hardware clock is set for UTC. The consequence of this is that all of the created /dev files get set to a future time when the hardware clock is actually set for localtime (which is highly desirable when dual-booting into Windows). And many programs tend to complain when device files are set to the future. Version-Release number of selected component (if applicable): dracut-002-13.4.1.git8f397a9b How reproducible: Always Steps to Reproduce: 1. echo "UTC=false" >>/etc/sysconfig/clock 2. hwclock --systohc --localtime 3. reboot 4. ls -l /dev/tty2 Actual results: 4. will show time some time info future or past depending on where you live Expected results: During boot the system clock should be correctly set using either a utc value or localtime value in hw clock so that the system clock doesn't suddenly change between time /dev populated and normal run-level. Additional info: Yes, it is possible to have Windows use UTC in hardware clock, but the boot process should use correct times. Wouldn't matter so much if /dev wasn't populated during the boot process (like it used to).
Actually the same applies to the real root, as long as the rules in /lib/udev/rules.d/88-clock.rules are not yet triggered, AFAIK.
I should also mention that for a lot of people WEST of UTC this isn't much of a problem. All of the files in /dev will look slightly older than they should be (eg. 5hr old if you are in NY), and no program will complain about that. But if you are EAST of UTC then there will be a problem because the times of the device files will be set at some time into the future (like 10hrs ahead in Australia) and programs will certainly complain about that. Also, my system doesn't have a 88-clock.rules. Where does that come from? Can you do a "rpm -qif" on that?
$ rpm -qf /lib/udev/rules.d/88-clock.rules initscripts-9.02.1-1.x86_64
In any case whatever is in 88-clock.rules is irrelevant because /dev has already been populated with device files created in the future during the boot sequence.
I would move a general "touch" to /sbin/start_udev (called by rc.sysinit) to be executed after the udev trigger.
udev-145-16.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/udev-145-16.fc12
udev-151-7.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/udev-151-7.fc13
udev-151-7.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update udev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-151-7.fc13
udev-145-19.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update udev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-145-19.fc12
udev-145-19.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
udev-151-7.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.