Shae,
> I ran e2fsck -f /dev/hda1 and get the following:
>
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking reference counts
> Pass 4: Checking group summary information
> /dev/hda1: 46180/256512 files (0.7% non-contigous), 219194/512064 blocks
This looks like a clean pass by e2fsck. I'd *guess* that you'd be able to boot
now...
> > These problems can occur due to various bugs in hardware and Linux. It's a case
> > of "you get what you pay for".
> >
> Everything should still be on warranty ( I just built it a 3 weeks ago), Would a dif
>hd prevent this in the future? Or are we talking a dif. m/b? It is a socket a
>system with apollo via kt133 chipset on a matsonic 8127c m/b. Would I be better off
>spending the extra $80 on asus a7v?
I'm talking about PC hardware and Linux in general. From memory the VIA make
decent chipsets. I can't say anything about Matsonic as a motherboard vendor.
>
> Kernel 2.2.18. I a startup script in rcS.d which contains this line 'hdparm -d 1 -c
>1 /dev/hda', but the boot process never gets that far. Running hdparm /dev/hda1
>shows me that dma is off, and 32 bit transfers are off as well. This is b/c script
>has not run yet.
> If this dma/VIA is a problem w/ this m/b, would it affect me even though hdparm
>tells me dma is disabled?
The 'hdparm -d 1 -c 1 /dev/hda' turned on DMA the last time you sucessfully
booted the system. It is not that using DMA *now* when you boot that is causing
the problem. At a guess is was silently corrupting your root file system all
the time you were running before. You only found out about it when you
rebooted.
If you can now mount teh root file system successfully (the e2fsck result
suggests you should be able to) I would disable the hdparm command in your
startup immediately, as coupled with the fact that you're running a VIA based
EIDE controller, the known problems with VIA/DMA/file system corruption is a
possible (although not definite) cause of your problem.
If you're up in multi-user mode halt the system immediately. Ideally you want
to do the following using a rescue floppy as any time you have the root
filesystem mounted rw you could be corrupting it. However, without a rescue
floppy type the following from the LILO prompt:
linux single
Login and comment out the hdparm entry in rcS.d. Reboot the system and you
should be able to get to multi-user with a reasonable expectation that we may
have fixed the problem.
> What are the chances that a this hdd would work (as is) under the asus a7v?
Again, you'll have the same problem, until you can clean up the file system.
Running without DMA enabled will impact your disk I/O performance. Do some more
research into the specifics of the VIA/DMA issue and then decide whether a new
motherboard is the quickest way to get you up and running with a stable config.
Others on the list might know more about this particular issue...
Gary
begin:vcard
n:Mulder;Gary
tel;fax:609-655-5114
tel;home:732-360-0282
tel;work:609-655-5105x28
x-mozilla-html:FALSE
url:http://www.cgen.com
org:Compugen, Inc.;Information Services Dept.
version:2.1
email;internet:[EMAIL PROTECTED]
title:System Administrator
adr;quoted-printable:;;7 Centre Drive=0D=0ASuite 7;Jamesburg;New Jersey;08831;USA
fn:Gary Mulder
end:vcard
