Cannot access the Hardware Clock via any known method

Hans de Goede j.w.r.degoede at hhs.nl
Wed Jan 30 14:30:05 UTC 2008


Deji Akingunola wrote:
> On Jan 30, 2008 8:46 AM, Steve Grubb <sgrubb at redhat.com> wrote:
>> Hi,
>>
>> I'm running an up to date rawhide machine. This message shows up everytime I
>> boot and my system time is always way off. Its been like this for over a
>> month. I figured somebody else would notice this and report it or fix it.
>> This is the full message:
>>
>> Cannot access the Hardware Clock via any known method.
>> Use the --debug option to see the details of our search for an access method.
>>
>> This occurs during boot. I have no idea where this is coming from. When I'm at
>> the command prompt, /dev/rtc exists. Any one else running x86_64 rawhide
>> notice this, too?
>>
> Yes,
> https://bugzilla.redhat.com/show_bug.cgi?id=409551
> https://bugzilla.redhat.com/show_bug.cgi?id=290731
> 

2 bugs, which as one can see I've been quite active in lately. Even offering a 
proof of concept fix, yet sofar it has been very silent around them.

I hope that this mailinglist thread will get some attention to this bug.

Short story:

the initrd used to create /dev/rtc (don't ask why) and then rc.sysinit runs 
hwclock --hctosys before doing anything else including before running udev

This no longer works as we've now switched from the old intel only rtc driver 
to the new generic rtc class which has a different major and minor number.

To make things harder, this major and minor number now gets allocated 
dynamically, although it seems that the new rtc class consistently is the first 
to claim a dynamic char major and thus always gets 254.

My proof of concept fix fixes things by letting mkinitrd check 
/boot/config-XXXX to detect old versus new rtc driver and use the correct major 
/ minor combi (cutting some corners  by using 254 as major for the new rtc 
class case)

That isn't the complete fix however as with the new rtc class driver as 
currently configured in the kernel the actual pc rtc driver called cmos_rtc is 
compiled as a module so my proof of concept also add that module to the initrd 
and insmod's it from the initrd.

I'm no where near sure that this is the correct fix. I wonder if /dev/rtc is 
needed during the initrd at all, and if it isn't I think that the initrd should 
not create it all. Then rc.sysinit should be modified to run hwclock after 
udev, or if there are reasons not to, create the /dev entry and load the driver 
itself.

Regards,

Hans




More information about the fedora-devel-list mailing list