Getting thrown into read-only mode - not able to remount
 

Hi!

Can anybody suggest any reasons why my FC6 system would get thrown into read-only mode? I boot happily in read-write, everything gets mounted and life is great.

Then, some time later (usually the order of several days to one month) for some reason that eludes me, my system suddenly gets switched to read-only mode.

I try remounting with: There is no error, but the system does not get remounted, either.


The only way so far I have found to get out of this situation is to reboot the system, which I'm not fond of doing.


Any ideas?

Check /var/log/messages. When a filesystem gets made RO, it's usually because a filesystem corruption was detected. The switch to RO is to protect the filesystem from further corruption, which could cause loss of data.

Boot off a rescue disk (the Fedora installation media can be used by entering "linux rescue" at the boot prompt), do not mount the disk filesystem, and run:

e2fsck -C -p -f -y /dev/ABCN

Where '/dev/ABCN' is the partition containing the filesystem (e.g., /dev/hda3, /dev/sdb1, etc.).

Ok, thank you for this.

e2fsck did seem to notice a few problems.

So... I guess I'll know for sure if my machine keeps running properly for more than a few days.


Thanks!

Not that it will make much difference, but
man:/e2fsck (ver. 1.40-WIP (02-Oct-2006)) says:

The man page is incorrect in this case.

Update: I've opened a bug against the e2fsck package to correct the documentation.

Thanks for the info. That explains why bugs me w/ Q's I did not expect &
works the way I thought it would w/o the "-n" option.

BTW, the author of the code recently joined LQ as "tytso". I don't know if he's also the author of the man page. Perhaps he might comment here.

Here it goes again!
 

Damn! After running e2fsck a few weeks ago as written in the previous posts, the same problem occurred again today.

Rather than throwing my box off a 20-story building, any other ideas about how I can track down the source of this problem?

I didn't notice anything in the logs that would seem relevant.

Did you run e2fsck again?

Did you reboot & did e2fsck run during reboot?

If so, & that fixed the problem, then I begin to suspect a dying HD.

Is it backed up? :)

Caution: If you did a default FC6 installation, your root file system is in a logical volume group, and running fsck on the device/partition containing a volume group can destroy the whole volume.

The only way to run fsck on a volume in a volume group is to run it on the /dev/<VG_name> created by the device mapper.

Do not run fsck /dev/hda2 if /dev/hda2 contains a logical volume group.

Thanks for the info./advice/warning, PTrenholme.

BTW, dleangen, did the orig. answers here fix the problem?

Make sure you are running (at least) an updated kernel. There was a low probability bug in the older vanilla kernels on which Fedora is based that could cause disk corruption.

yum update kernel

or, even better:

yum update

Yes to all of the above.

Is there any way to run thorough tests on the HD so I _know_ what's going on?

(Unfortunately, I don't have access to the machine again for a few weeks, so I can't try updating the kernel just yet.)


Thanks to all!!

Read the smartctl man page & run some tests & ask some more Q's.

smartctl shows no errors
 

Well, it seems to me that smartctl is not showing any errors.

This is the output:

Does this mean that my disk is ok and that the error must be due to something else? Or are there some other tests that I should run on the disk?


BTW, I wasn't sure how to capture the log for the "extended test". Any hints on that?

Thanks so much!

From your response above: