Description of problem:
I'm 99% sure this is due to redhat-config-date, but not 100%.
My original "clock" had ARC "no" or "false", not "true". Now it's
$ cat /etc/sysconfig/clock
This causes problems in hwclock invocation at startup and shutdown because --arc
is used which is not supported by hwclock.
+ '[' -f /etc/sysconfig/clock ']'
+ . /etc/sysconfig/clock
+ '[' '' = GMT ']'
+ '[' '' = ARC ']'
+ CLOCKFLAGS= --hctosys
+ CLOCKFLAGS= --hctosys --utc
+ CLOCKDEF= (utc)
+ CLOCKFLAGS= --hctosys --utc --arc
+ CLOCKDEF= (utc) (arc)
+ /sbin/hwclock --hctosys --utc --arc
/sbin/hwclock: unrecognized option `--arc'
hwclock - query and set the hardware clock (RTC)
Version-Release number of selected component (if applicable):
checked changelog for beta4 and didn't see anything related to this bug, so I
assume it's still there.
Run redhat-config-date, don't know exactly the necessary steps.
I discovered this sometime after I used the app and linked problem to it looking
at "clock" file mod date and rpm install date.
According to 'man hwclock', '--arc' is a valid option. Also, according to Bill
Nottingham in bug #72149, ARC is a true/false field, so I believe that the
/etc/sysconfig/clock file that redhat-config-date has written is correct.
Changing the component to util-linux, which is the package that hwclock is from.
I would guess the real problem is that redhat-config-date interpreted the original "ARC=no"
line as meaning "ARC=true", and rewrote the clock file that way...?
Since /etc/rc.d/rc.sysinit really expects ARC usage to come by the CLOCKMODE=ARC
setting rather than ARC=true,
redhat-config-date should probably make sure that it only pays attention to
hwclock probably only has (and can have) a --arch option when built on the Alpha. This is
one of those "not supposed to happen" situations that did.
Should be fixed with redhat-config-date-1.5.9.
*** Bug 83383 has been marked as a duplicate of this bug. ***
Fix confirmed with redhat-config-date-1.5.9-4.