On RHEL5 and CentOS-5 with a recent kernel, depending upon the hardware being used, the RTC may not be accessible. This can be checked by executing /sbin/hwclock --debug. This is a regression in more recent kernels than 2.6.18 (kernel change has not been identified yet, goes back to at least 2007). During boot /dev/rtc is missing, and since this is needed by hwclock before starting udev, there is no proper way to fix it unless we modify the infrastructure from the vendor (/etc/rc.sysinit). The fix could be as easy as to symlink to /dev/rtc0 or creating the /dev/rtc device node with the newer major/minor, which is tested and works. A new CONFIG option providing this backward compatibility would be welcome.
Has this problem been reported to Red Hat? While it _originally_ was a regression, it's been there for so long that I think it's more appropriate to ask Red Hat to provide a workaround.
You have to be a Red Hat customer for them to take notice (CentOS has a majority in the RHEL+clone world), besides they don't support running custom kernels. I understand that this regression is something that should have been reported earlier (we hope to change this in the future with our kernel-ml offering for RHEL5), however a special "compatibility" CONFIG option might as well create the old /dev/rtc when enabled. The amount of code should be quite minimal, easy to support and only enabled for those that use it. We could even indicate that it is needed for RHEL5 and older (which go EOL in about 3 years), so there is a clear end to this support.
Reply-To: david-b@pacbell.net A similar failure on an Ubuntu 10.0.4 laptop looks to be a permissions problem; "sudo hwclock" works. Please report whether "sudo" helps your config too. Agreed that reading /dev/rtc should be something anyone can do; that's the traditional way hwclock works. Maybe the last person to touch that code broke it; fiilesystem permissions looked sane, fwiw
No. The problem is that /dev/rtc moved to /dev/rtc0, and the device node moved from 10:135 to 25?:0 and older systems are not prepared for this. Also the device node should exist before udev is called due to older scripts expecting it there.
Reply-To: david-b@pacbell.net \ > No. > > The problem is that /dev/rtc moved to /dev/rtc0, Should be no problem at all given symlink. and the > device node moved from > 10:135 to 25?:0 and older systems are not > prepared for this. Also the device > node should exist before udev is called due to > older scripts expecting it there. That's the problem. ISTR needing to add code to the RTC framework to make sure the major/minor IDs for RTC0 were correct (e.g. major 135 sounds like an Officially Assigned one ... I vaguely recall a kernel patch to use that, ages ago. Looks like someone -- related t udev or some defauult /dev setup? broke that longstanding policy/convention... And should fix their bug.