outpost:~# clock mktime() failed unexpectedly (rc -1). Aborting. outpost:~# rpm -qf /sbin/clock util-linux-2.7-15 outpost:~# cat /etc/redhat-release release 5.0 (Hurricane) outpost:~# uname -a Linux outpost.boehm.org 2.0.35 #1 Thu Oct 29 16:02:50 CET 1998 i586 unknown outpost:~# uptime 4:12am up 184 days, 14:46, 1 user, load average: 0.01, 0.02, 0.00 outpost:~# cat /proc/cpuinfo processor : 0 cpu : 586 model : Pentium 75+ vendor_id : GenuineIntel stepping : 5 fdiv_bug : no hlt_bug : no f00f_bug : yes fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips : 36.04 is this a hardware problem or is it the clock util? i normally periodically use `clock -uw` or `hwclock -uw` to sync my hwclock... problem first appeared on 0101-2000 01:01 (well.. that's the first time it was in use since the new year).
*** Bug 8134 has been marked as a duplicate of this bug. ***
*** Bug 8108 has been marked as a duplicate of this bug. ***
I'm seeing the same problem with util-linux-2.8-11, under Red Hat 5.2. With that version, at least, the error message only shows up when /dev/rtc is not available (e.g. if it's busy due to some other software like VMware), in which case hwclock is going directly to the hardware clock. The following patch seems to have fixed the problem for me. --- util-linux-2.8/sys-utils.orig/hwclock.c Thu Jun 11 17:30:55 1998 +++ util-linux-2.8/sys-utils/hwclock.c Fri Jan 7 15:07:01 2000 @@ -845,6 +845,9 @@ */ if (hclock_read_bcd(9) >= 70) tm->tm_year = hclock_read_bcd(9); else tm->tm_year = hclock_read_bcd(9) + 100; + if (debug) + printf ("Year read from old Hardware Clock: c=%02d, y=%02d, tm_year=%02d\n", + hclock_read_bcd(50), hclock_read_bcd(9), tm->tm_year); } else { tm->tm_year = hclock_read_bcd(50) * 100 + hclock_read_bcd(9) - 1900; /* Note: Byte 50 contains centuries since A.D. Byte 9 contains @@ -854,6 +857,10 @@ conceivably be years since the beginning of the current century. If so, this code won't work after 1999. */ + if (tm->tm_year < 70) tm->tm_year += 100; /* Y2K bug */ + if (debug) + printf ("Year read from new Hardware Clock: c=%02d, y=%02d, tm_year=%02d\n", + hclock_read_bcd(50), hclock_read_bcd(9), tm->tm_year); } /* Unless the clock changed while we were reading, consider this a good clock read . This fix is essentially just the one line. The debug printf code is not necessary, of course, but it helped me to find out what was going on. After running the patched hwclock program, with the -w option, the century byte was correctly updated, and now shows up as 20, as it should. (I imagine that rebooting the system would have allowed the BIOS to update the century byte on its own, which would have eliminated the need for this patch, but it wasn't convenient for me to reboot the system in question.)
This is fixed in the current util-linux.