Reproducible: always Steps to reproduce: /etc/init.d/hwclock start Output: * Setting system clock using the hardware clock [Local Time] ... Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. * Failed to set the system clock [ !! ] Reason: The device file /dev/rtc doesn't exist. modprobe rtc_cmos is required to create /dev/rtc and hwclock starts with no problems
Better post your .config for that kernel to see what is the status of your CONFIG_RTC, CONFIG_GEN_RTC and CONFIG_RTC_CLASS.
Created attachment 163740 [details] kernel-2.6.26-tuxonice .config attached for 2.6.26-tuxonice
If you need to do 'modprobe rtc-cmos' instead of 'modprobe rtc', then to make rtc-cmos autoload, edit /etc/modprobe.d/pnp-aliases and change alias pnp:dPNP0b00 rtc to alias pnp:dPNP0b00 rtc-cmos
Or you could go with GEN_RTC - either way it's a local configuration issue, not something that could be incorporated into Gentoo Linux generically... But maybe the documentation people want to spend a line or two on it in the installation handbook.
Yep, thanks for looking into this. Wormo's suggestion works just fine. However, I would like to point out that the exact same .config for 2.6.25 behaves as expected. As Jeroen suggested, it's more of a documentation issue. Thanks.
Reopening because didn't realize that this has already been assigned to Docs Team. Was thinking of opening a new bug.. Anyways, my bad!
It's an ~arch package, so we don't document that sort of thing. More to the point, tuxonice is *not* a supported kernel, so we can't go sticking in references to unsupported packages in our documentation. Besides, single line config issues like this more properly belong in the ebuild, in a postinstall message, or even in a pre-install "die"-type check. Similar to ebuilds that require notify support in the kernel.
(In reply to comment #7) > It's an ~arch package, so we don't document that sort of thing. More to the > point, tuxonice is *not* a supported kernel, so we can't go sticking in > references to unsupported packages in our documentation. It's nothing tuxonice specific - vanilla- and gentoo-sources have RTC_CLASS as well. 2.6.26 _is_ going stable in a little while. > Besides, single line config issues like this more properly belong in the > ebuild, in a postinstall message, or even in a pre-install "die"-type check. > Similar to ebuilds that require notify support in the kernel. CC'ing for sys-apps/util-linux. If you don't like being the assignee, then at least bounce it back to bug-wranglers...
(In reply to comment #8) > CC'ing for sys-apps/util-linux. If you don't like being the assignee, then at > least bounce it back to bug-wranglers... Right, sorry 'bout that. Forgot that there were folks 'round that can actually fix the ebuilds -- I sure can't. Reassigning to base-system.
But base-system can't fix documentation issues, which is what this is...
My issue got solved and I was hoping we come up with something so that this doesn't happen to someone else; doesn't look like. I think the best way for someone stuck with a similar issue is to come to this bug and try out the fix suggested. Closed as fixed.
Please stop messing with this bug, y'all. Let's try this approach - maybe kernel team can confirm that the default (oldconfig, etc) for 2.6.26 in a Gentoo stable version will provide some kind of /dev/rtc to prevent this problem.
roy: init.d/hwclock needs to change to look for the other module, and also potentially other rtc devices. The attached patch I wrote blind as I can't reboot to test it now, but it should work.
Created attachment 164505 [details, diff] openrc-0.2.5-hwclock-rtc-device.patch
I have an easier solution, no patching or anything, simply build the module rtc-cmos into the kernel. It worked for me.
Comment on attachment 164505 [details, diff] openrc-0.2.5-hwclock-rtc-device.patch hwclock already searches the RTC framework when /dev/rtc doesnt exist, so specifying --rtc by default will break systems. as will the logic for looking for devices and failing when they dont exist. i would simply add rtc-cmos to the modprobe list and call it a day. trying to autodetect the appropriate driver for the RTC framework is a nightmare and totally not worth the effort.
Ok, as a middle ground, how about adding a var for rtc_module, which defaults to rtc-cmos (I do have a machine with a different RTC chip). So then the only change to the code is: modprobe -q ${rtc_module} || || modprobe -q rtc || modprobe -q genrtc And we'll revisit it later if anybody turns up with a multiple-RTC system.
Fixed here http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=e48d5d1e7eda2b9db84947ef926b698ad0ca9bdc Thanks!
i'd point out that this doesnt work with a static /dev, but whatever ... not like those people exist anymore
*** Bug 261097 has been marked as a duplicate of this bug. ***