Dan Morrill (morrildl@nycap.rr.com)
Tue, 9 Mar 1999 23:43:22 -0500 (EST)
I have a SCSI CD drive in my SX164, so I suffer from the kernel oops that results
if you attempt to load sr_mod as a module.
I built 2.2.3 to see if it had been fixed, and did a test modprobe, and
discovered that it is, in fact, not fixed yet.
My problem is that, like an idiot, I forgot to sync before doing the modprobe.
The next reboot (after the kernel oops and subsequent power cycle), fsck turned
up a bunch of bad/duplicate blocks and dropped into single-user mode. I ran
fsck manually, answered yes to all the questions about fixing bad blocks, watched
a bunch of files go by (mostly in /var/run, so I wasn't *too* worried), and
rebooted.
The system comes back up fine. The only permanent problem I've found is that
my clock now thinks it's 2019 (a la Red Hat 5.1). The AlphaBIOS (v5.62) says
it's 1999, and if I do an `rdate -s time.gmt.org` and run `clock` from a prompt,
clock gives the correct date.
I poked around some and discovered that /sbin/clock is dying whenever it gets
the -a option (which instructs it to actually change the CMOS) with a floating
point exception. This, needless to say, strikes me as a rather weird result of
a filesystem recovery. I reinstalled the clock .rpm from my RH 5.2 CD, to no
avail. I've checked, and "-a -A -u" is actually getting passed to clock from
/etc/rc.d/rc.sysinit, so I guess that I've somehow broken clock so that it is
dying on the "-a" during startup, thereby failing to set my clock.
So, does anyone have any idea what the fsck happened to my clock? More
importantly, does anyone know how I can clean my clock? (Sorry, I couldn't
resist. ;)
The moral of the story, of course, is "Always sync. Sync is your friend."
Dan Morrill
Computer Scientist, Physicist
-- To unsubscribe: send e-mail to axp-list-request@redhat.com with 'unsubscribe' as the subject. Do not send it to axp-list@redhat.com
This archive was generated by hypermail 2.0b3 on Tue Mar 09 1999 - 21:00:18 PST