Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#9636 - [initscripts-2008.02-1] "Cannot access the hardware clock" error message on start

Attached to Project: Arch Linux
Opened by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 08:14 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 29 March 2008, 22:20 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description: Since I upgraded less than an hour ago udev to its last version, I get a "Cannot access the hardware clock via any known method" error message.

A little google tells me it's related to udev. Can't say if it can be seen on i686.


Additional info:
* udev-118-2


Steps to reproduce: Just update udev and reboot your arch ;)

Not a killing bug, but it seems to slow down a little (around 3% ?!) boot time.
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Saturday, 29 March 2008, 22:20 GMT
Reason for closing:  Fixed
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 10:00 GMT
Could be an initscript issue, because this error shows just before udev start. Or even a mkinitrd bug ?!

Found this thread, showing this bug on fedora "trunk", thread 3 weeks old...

Could have some more infos ?!

fedora-devel-list@redhat.com/8500636.html"> http://www.opensubscriber.com/message/fedora-devel-list@redhat.com/8500636.html

Comment by Jan de Groot (JGC) - Thursday, 21 February 2008, 10:13 GMT
From the initscripts changelog:
Allow --directisa configuration for hwclock calls

Look in /etc/rc.conf for a line like this:
USEDIRECTISA="yes"

Without that one, the initscripts won't use the directisa parameter, which could fail on your system.

@Other devs: can't we make this one the default when there's no USEDIRECTISA setting in rc.conf? Some (most?) people don't merge their rc.conf after an upgrade.
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 10:16 GMT
Erh...

I added this line in my /etc/rc.conf and it changed nothing. Same error at startup.
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 10:34 GMT
@Jan, isn't this enought?
50 if [ "$USEDIRECTISA" != "no" ]; then
51 HWCLOCK_PARAMS="$HWCLOCK_PARAMS --directisa"
52 fi
Comment by Jan de Groot (JGC) - Thursday, 21 February 2008, 10:35 GMT
Hmm, looks logical:
we use hwclock to set the time before udev is started, which means /dev isn't populated yet. hwclock needs /dev/rtc, which isn't there. The simple workaround is to have a /dev/rtc in /dev before a ramdisk is mounted there.
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 10:47 GMT Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 11:08 GMT
@Frederic: btw, what initscripts version do you use?
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 11:12 GMT
$ yaourt -Si initscripts
Dépôt : testing
Nom : initscripts
Version : 2008.02-1
URL : --
Licences : --
Groupes : base
Fournit : --
Dépend de : glibc bash awk grep coreutils sed udev>=118
net-tools ncurses
Dépendances opt. : --
Incompatible avec : --
Remplace : --
A télécharger : 17,28 K
Taille (installé) : 17,28 K
Paqueteur : --
Architecture : --
Compilé le : --
somme MD5 : a3ed28b214423554c6c9fa85845d8b5b
Description : System initialization/bootup scripts

Latest in testing I think ?
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 11:45 GMT
After looking at: https://bugzilla.redhat.com/show_bug.cgi?id=290731#c14
I think the following should fix the issue:
1) include rtc_cmos.ko in initcpio image
2) make sure it is loaded before hwclock
3) create /dev/misc/rtc0 with device numbers 254, 0
4) create /dev/rtc symlink to /dev/misc/rtc0

Note that this works with kernels >= 2.6.24 only, old kernels use just /dev/rtc with numbers 10, 135
Also, I'm not sure if support for other RTC drivers is needed.
Comment by Jan de Groot (JGC) - Thursday, 21 February 2008, 11:46 GMT
mknod /dev/rtc c 10 135 would be fine in the file referenced by Roman.
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 11:49 GMT
@Jan: this will produce:
Udev started: udev-devent[919]: node_symlink: device node '/dev/rtc' already exists, link to '/dev/rtc0'
according to the bugreport referrenced above, see my previous comment
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 16:04 GMT
weird, I don't see any error message with both USEDIRECTISA="yes" and USEDIRECTISA="no" :-/
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 16:10 GMT
@Frederic: do you use some specific motherboard?
it seems your system doesn't allow direct setting of CMOS by hwclock, so it falls back to using /dev/rtc.
Sure, it's still a bug, I'm just curious about the hardware.
EDIT: I guess this is the same kind of hardware that required us to introduce the USEDIRECTISA option.
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 16:56 GMT
My motherboard ?

An acer one, based on VIA K8M800 chipset. 2 and half years old (October 2005) for a Sempron 3100+ => Acer Aspire T135.

If sysinfo is right :

MOTHERBOARD
Host bridge
Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Subsystem: VIA Technologies, Inc. K8M800 Host Bridge
PCI bridge(s)
VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode])
USB controller(s)
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI])
ISA bridge
VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Subsystem: Giga-byte Technology GA-7VT600 Motherboard
IDE interface
VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology GA-7VAX Mainboard
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 16:57 GMT
I have to add before this initscripts update, I had no problem with my hw clock. And no slow down on boot.
Comment by Aaron Griffin (phrakture) - Thursday, 21 February 2008, 17:03 GMT
@Jan: Does udev autocreate that device node?

Perhaps adding MODULES="rtc_cmos" to the mkinitcpio image will help?

I *think* this is hardware specific, as it doesn't happen on my machine. However, it IS mostly cosmetic...

Recommended fix? Just pre-create a /dev/rtc node?
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 17:42 GMT
well, yes.
for .24 kernels - as in #3 & #4 I've said above,
for .23 kernels - as Jan said.
users with hardware problems could add rtc module to their mkinitcpio by hand (it could be also statically compiled it into kernel, but I don't like that)

@Frederic: you'll have to test the soultion by yourself, because we cannot do this on our hardware.
please try to add MODULES="rtc_cmos" to mkinitcpio.conf and rebuild the image,
if that won't help - try also adding #3 and #4 before the first hwclock call in rc.sysinit
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 17:55 GMT
Ok. But where can I find a step by step howto for doing this ?

Besides a little slow down on start and the error message, everything is ok.
Comment by Aaron Griffin (phrakture) - Thursday, 21 February 2008, 18:09 GMT
Roman, fixing this for .23 kernels is stupid. We do not have that kernel anymore. This is ArchLinux, not ubuntu.

Frederic, I will look into fixing this at the package level so you do not need to do anything. One of my machines had a similar error on boot, so I can verify it working or not
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 18:10 GMT
@ Aaron: sure, I just mentioned this for referrence.
Comment by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 18:25 GMT
Aaron : thanks a lot. I don't have a lot of time in front of me right now. And anyway, if this packages goes into "stable" repo, a lot of people could see it.

Comment by Aaron Griffin (phrakture) - Thursday, 21 February 2008, 22:27 GMT
@Frederic: I will not be home for a bit. If you have time to test, it's be nice if you could try the following:

Edit /etc/rc.sysinit and go to line 25. Underneat the 3 mknod calls, add the following lines:

/bin/mknod /dev/misc/rtc0 c 10 135
/bin/ln -s /dev/rtc /dev/misc/rtc0

the "10 135" might need to be "0 254" - I think Roman knows better here. This shouldn't harm anything, but I can't test it for some time.
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 22:31 GMT
"0 254" for .24 kernels according to RedHat's bugreport
Comment by Aaron Griffin (phrakture) - Thursday, 21 February 2008, 22:37 GMT
Weird:
$ ll /dev/misc/rtc
crw-rw-r-- 1 root audio 10, 135 2008-02-20 18:33 /dev/misc/rtc
$ uname -r
2.6.24-ARCH
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 23:05 GMT
Aha!

https://bugzilla.redhat.com/show_bug.cgi?id=290731#c4
Red Hat has:
# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
CONFIG_RTC_DRV_CMOS=m

We have
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_RTC_DRV_CMOS=m

As I understood from reading some more comments - CONFIG_RTC is "the old driver" (10 135),
and when it's disabled - the device is "0 254".

BTW, it seems CONFIG_RTC and CONFIG_GEN_RTC should not be enabled at the same time,
this is fixed in .25 tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=09b6bdb3b6a95fe270107c2831e033f9cb233d2d

I think our kernel config could be improved in RTC section, I'm digging more into it...
Comment by Roman Kyrylych (Romashka) - Thursday, 21 February 2008, 23:26 GMT
ok, moving RTC config issues to  FS#9649  to stop bugspamming here. :)
Comment by Eric Belanger (Snowman) - Friday, 22 February 2008, 06:24 GMT
I have the same problem on my x86_64 system, I tried creating the /dev/misc/rtc0 device with different MJAJOR and MINOR then running the hwclock command but it didn't work.
Comment by Greg (dolby) - Friday, 22 February 2008, 14:46 GMT
initscripts need to change printhl "Copyright 2002-2007 Judd Vinet" to printhl "Copyright 2002-2008 Judd Vinet-Aaron Griffin" or something too :P
Comment by Greg (dolby) - Friday, 22 February 2008, 14:46 GMT
in rc.sysinit OFC
Comment by Aaron Griffin (phrakture) - Friday, 22 February 2008, 20:14 GMT
@dolby: One bug per report please
Comment by Filip Wojciechowski (fwojciec) - Sunday, 02 March 2008, 02:47 GMT
I tried adding the module to initcpio image + the two lines to rc.sysinit script but it didn't work -- whatever I tried I got the added lines printed out in error during startup with an added message that "the file doesn't exist" -- or something to that effect anyways.
Comment by Pierre Schmitz (Pierre) - Tuesday, 04 March 2008, 12:03 GMT
I have the same problem on my x86_64 machine. However: after boot-up the hwclock call works fine.
Comment by Aaron Griffin (phrakture) - Wednesday, 05 March 2008, 23:31 GMT
I do to, and I have no been successful in getting rid the error.

Suggestions?
Comment by Roman Kyrylych (Romashka) - Wednesday, 05 March 2008, 23:37 GMT
Aaron - try the same with /dev/rtc symlink to -> /dev/misc0/rtc0 (0 254) with the latest kernel package (2.6.24.3-2)
Comment by Aaron Griffin (phrakture) - Wednesday, 05 March 2008, 23:43 GMT
I believe I tried both, but I will check again.
Comment by Levent (Levent) - Friday, 07 March 2008, 21:53 GMT
I can confirm this Bug, i got this on two pc.
They are both running on AMD 690G based Boards with HPET activated and both have the newest testing-kernel.
Comment by Roman Kyrylych (Romashka) - Friday, 07 March 2008, 22:24 GMT
@Levent: did you try this?
edit /etc/rc.sysinit and go to line 25. Underneat the 3 mknod calls, add the following lines:
/bin/mknod /dev/misc/rtc0 c 0 254
/bin/ln -s /dev/rtc /dev/misc/rtc0
Comment by Roman Kyrylych (Romashka) - Saturday, 08 March 2008, 16:41 GMT
ok, thanks to tpowa for implementing a real fix,
going to git soon...
Comment by Aaron Griffin (phrakture) - Friday, 14 March 2008, 18:12 GMT
Is this fixed in git, Roman?
Comment by Roman Kyrylych (Romashka) - Friday, 14 March 2008, 21:31 GMT
yes
tpowa did the testing on his hardware
Comment by Filip Wojciechowski (fwojciec) - Tuesday, 18 March 2008, 17:29 GMT
After installing the latest version of filesystem package (filesystem 2008.03-2) the problem is not fixed on my computer, it is made worse -- at least in the sense that there are additional error messages printed during boot. I don't know if I copied it down exactly but the additional error messages look something like this:
/bin/mkdir /dev/misc/bin/: no such file or directory
/bin/mknod /dev/misc/rtc: no such file or directory
Followed by the usual error message about not being able to access hardware clock...


I also get two additional errors (which my or may be related) -- during the first udev startup step (udev 118-6):
(...) /dev/pts: file exists
(...) /dev/shm: file exists
Comment by Filip Wojciechowski (fwojciec) - Tuesday, 18 March 2008, 19:11 GMT
With the updated filesystem package (filesystem 2008.03-2) the hw clock issue seems to be completely fixed -- at least there are no more error messages, not even the one about not being able to access hardware clock. I'm also not getting the error about last write time being in the future during filesystem check.

The two latter errors (/dev/pts and /dev/shm) still show up though -- the problem seems to be that the directories mkdir command tries to create (/dev/pts and /dev/shm) are somehow created earlier and already exist... The mkdir command for these directories is apparently called twice in the latest rc.sysinit -- lines 34-35 and 82-83).
Comment by Roman Kyrylych (Romashka) - Tuesday, 18 March 2008, 22:12 GMT
All fixed in initscripts-2008.03-3.
Eric, Pierre, please confirm.
Comment by Pierre Schmitz (Pierre) - Tuesday, 18 March 2008, 23:01 GMT
I still get that error message during boot-up. But, hwclock does work after booting.
Comment by Roman Kyrylych (Romashka) - Tuesday, 18 March 2008, 23:07 GMT
Pierre, did you try with USEDIRECTISA="yes" or "no"?
Comment by Pierre Schmitz (Pierre) - Tuesday, 18 March 2008, 23:08 GMT
Yes, I tried both.
Comment by Roman Kyrylych (Romashka) - Tuesday, 18 March 2008, 23:16 GMT
hm, could you try calling hwclock with strace in rc.sysinit maybe,
I don't know where to look for the issue :(
will try to search more tomorrow (gtg sleep now).
Comment by Filip Wojciechowski (fwojciec) - Wednesday, 19 March 2008, 00:03 GMT
The initscripts (2008.03-2 -> 2008.03-3) upgrade fixes the hwclock issue on my system (USEDIRECTISA="yes", in case it matters).

The package seems to introduce a new problem, though -- "/sbin/minilogd" from line 38 returns "No such file or directory" error.
Comment by Eric Belanger (Snowman) - Wednesday, 19 March 2008, 03:28 GMT
initscripts 2008.03-3 fixes the hwclock issue but I'm also getting the minilog error. The minilog error only happens on my x86_64 system which had the hwclock problem. My i686 system which worked fine with previous initscripts packages works fine.
Comment by Roman Kyrylych (Romashka) - Wednesday, 19 March 2008, 07:19 GMT
Sorry about x86_64 package. :-(

Pierre, it seems you're the only one left.
Could you try these variants:
1) call `modprobe rtc_cmos` (and try to load other rtc_* too) before hwclock in rc.sysinit
2) see what device number /dev/misc/rtc0 has after boot, and if there is /dev/misc/rtc1, and also if `lsmod | grep rtc` after boot shows something other than rtc_core and rtc_cmos.
Comment by Pierre Schmitz (Pierre) - Wednesday, 19 March 2008, 07:45 GMT
Increasing the device number fixes the problem for me. Change

/bin/mknod /dev/misc/rtc0 c 252 0

to

/bin/mknod /dev/misc/rtc0 c 253 0
Comment by Roman Kyrylych (Romashka) - Wednesday, 19 March 2008, 07:51 GMT
Hm, it's 253 0 in my VMware too (though I don't get any errors even with DIRECTISA="no").
Eric. could you check if 253 breaks hwclock again on your system?
Comment by Roman Kyrylych (Romashka) - Wednesday, 19 March 2008, 09:26 GMT
Guys, please try the attached patch
Comment by Pierre Schmitz (Pierre) - Wednesday, 19 March 2008, 10:08 GMT
That patch works for me. Thanks.
Comment by Filip Wojciechowski (fwojciec) - Wednesday, 19 March 2008, 12:14 GMT
The patch works for me as well.

Loading...