Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 235647 - have hwclock init script detect newer rtc-cmos module
Summary: have hwclock init script detect newer rtc-cmos module
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 261097 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-25 02:46 UTC by Bandan
Modified: 2009-03-04 06:47 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
kernel-2.6.26-tuxonice (.config,71.51 KB, text/plain)
2008-08-25 05:38 UTC, Bandan
Details
openrc-0.2.5-hwclock-rtc-device.patch (openrc-0.2.5-hwclock-rtc-device.patch,1.61 KB, patch)
2008-09-03 20:01 UTC, Robin Johnson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bandan 2008-08-25 02:46:56 UTC
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
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-08-25 05:21:37 UTC
Better post your .config for that kernel to see what is the status of your CONFIG_RTC, CONFIG_GEN_RTC and CONFIG_RTC_CLASS.
Comment 2 Bandan 2008-08-25 05:38:01 UTC
Created attachment 163740 [details]
kernel-2.6.26-tuxonice

.config attached for 2.6.26-tuxonice
Comment 3 Wormo (RETIRED) gentoo-dev 2008-08-25 06:36:39 UTC
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 
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2008-08-25 20:03:08 UTC
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.
Comment 5 Bandan 2008-08-25 20:47:45 UTC
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.
Comment 6 Bandan 2008-08-25 20:50:15 UTC
Reopening because didn't realize that this has already been assigned to Docs Team. Was thinking of opening a new bug.. Anyways, my bad!
Comment 7 nm (RETIRED) gentoo-dev 2008-08-25 21:48:17 UTC
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.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2008-08-25 23:51:25 UTC
(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...
Comment 9 nm (RETIRED) gentoo-dev 2008-08-26 05:25:11 UTC
(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.
Comment 10 Doug Goldstein (RETIRED) gentoo-dev 2008-08-30 00:26:05 UTC
But base-system can't fix documentation issues, which is what this is...
Comment 11 Bandan 2008-08-30 01:38:29 UTC
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.

Comment 12 Jeroen Roovers (RETIRED) gentoo-dev 2008-08-30 06:20:49 UTC
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.
Comment 13 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-03 20:01:20 UTC
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.
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-03 20:01:49 UTC
Created attachment 164505 [details, diff]
openrc-0.2.5-hwclock-rtc-device.patch
Comment 15 Billy DeVincentis 2008-09-08 17:12:38 UTC
I have an easier solution, no patching or anything, simply build the module rtc-cmos into the kernel. It worked for me.
Comment 16 SpanKY gentoo-dev 2008-09-25 07:22:18 UTC
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.
Comment 17 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-25 08:02:14 UTC
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.
Comment 19 SpanKY gentoo-dev 2008-10-26 07:08:35 UTC
i'd point out that this doesnt work with a static /dev, but whatever ... not like those people exist anymore
Comment 20 SpanKY gentoo-dev 2009-03-04 06:47:59 UTC
*** Bug 261097 has been marked as a duplicate of this bug. ***