Description of problem: With initscripts-8.15-1 the following started to show up on x86_64 machine (but not on i386): Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Setting clock (utc): Wed Sep 28 00:40:13 MDT 2005 [ OK ] Starting udev: [ OK ] ..... It would appear that "Cannot access" message comes from a call to /sbin/hwclock in /etc/rc.d/rc.sysinit. But running /sbin/hwclock --hctosys --utc from a command line works silently. If I will try /sbin/hwclock --hctosys --utc --debug I see the following: hwclock from util-linux-2.13-pre2 Using /dev/rtc interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... /dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change ...got clock tick Time read from Hardware Clock: 2005/09/28 07:29:02 Hw clock time : 2005/09/28 07:29:02 = 1127892542 seconds since 1969 Calling settimeofday: tv.tv_sec = 1127892542, tv.tv_usec = 0 tz.tz_minuteswest = 360 There are obvious pieces of Alpha support in /etc/rc.d/rc.sysinit; but these, AFAICS do not execute. I do not see why the quoted message started to show. Looking at the wrong places? Version-Release number of selected component (if applicable): initscripts-8.15-1
Are there any AVC messages in the log?
> Are there any AVC messages in the log? No, nothing of that sort. I was booting that with 'selinux=0' anyway. "Cannot access the Hardware Clock ..." obviously comes from /sbin/hwclock, as that string is not hard to find there, but so far I cannot figure why. 'util-linux-2.13-0.3.pre2', which supplies /sbin/hwclock, was installed on 2005-09-08 but the message showed up only after yesterday updates.
Forgot to add. Booting an earlier kernel, where this was not happening previously, is still producing the same message. There is not outright obvious harm from that. As quoted boot messages show clocks are set anyway.
If you change the invocation to 'strace -o /dev/hwclock.$$ hwclock ...', is there anything interesting in that output?
'strace' is /usr/bin/strace. :-) Indeed, there is. Here: getuid() = 0 open("/dev/rtc", O_RDONLY) = -1 ENOENT (No such file or directory) open("/dev/misc/rtc", O_RDONLY) = -1 ENOENT (No such file or directory) getcwd("/", 4098) = 2 write(2, "Cannot access the Hardware Clock"..., 55) = 55 getcwd("/", 4098) = 2 write(2, "Use the --debug option to see th"..., 78) = 78 getuid() = 0 sendto(3, "D\0\0\0W\4\5\0\1\0\0\0\0\0\0\0hwclock: .... but when you look later /dev/rtc is there. Dropping a few 'echo /dev/rt*' in rc.sysinit shows that /dev/rtc appears only after udev was running but hwclock want to see that earlier (and still claims that time was set fine).
Hm. We really want to set the clock as early as possible. One solution is to create /dev/rtc along with null, zero, etc. in the initramfs. CC'ing mkinitrd maintainer.
Dropping into rc.sysinit [ -c /dev/rtc ] || mknod /dev/rtc c 10 135 just before you attemtp to run hwclock does not require hacking mkinitrd and looks that it works just fine. It also keeps the whole mess in one place.
This was fixed in mkinitrd-5.0.1-1.