fedora 8 hacked?

Roger Heflin rogerheflin at gmail.com
Sat Apr 26 17:26:37 UTC 2008


tom lee wrote:
> On Sat, Apr 26, 2008 at 9:20 AM, Roger Heflin <rogerheflin at gmail.com> wrote:
> 
>> Because, if you keep writing to a corrupted filesystem you can end up
>> destroying the entire filesystem completely and lose *ALL* of your data and
>> that is worse.
> 
> I agree with you. That is why I think the OS should better off with
> reboot "showdown -r -F now"
> instead of mounting as read-only. if there is potencial disk problem,
> you need to run this command anyway no matter what problems you may
> find before rebooting.

If you automatically reboot, you make the problem go away, but don't have any 
details on what happened (cannot log) so it *WILL* happen again, automatically 
reboot helps recover from the issue, but results in the loss of all details that 
could be used to fix the issue.

> 
>> The problem is that it may or may not crash before it destroys the
>> filesystem competely, and if the OS is written robustly it should not crash
>> just because the filesystem tables are corrupted (and Linux has done some
>> testing with something that puts random data on the filesystem to make sure
>> that it does not crash in those random corrupted data cases).
>>
>>
>>>
>>>> From this perspective, I  think microsoft way of crasing is a better
>>>>
>>> design. at least you know some wrong right away and reboot the
>>> computer automatically can get it fixed.
>>>
>> That was not their design, MS tends to try to work around errors rather than
>> report the errors, so if then you get an error, it tries to cope and then
>> you get a completely unrelated cryptic error that really tells you nothing.
>> If if the crash said nothing useful to identify the failing component is it
>> useless, you have no idea what to fix, just crashing tells someone nothing.
>>
>> If you had checked dmesg there should have been a clear error indicating
>> what happened, if all of the partitions on the filesystem were RO then I
>> would suspect that the disk itself quit talking, next time make sure to
>> check dmesg and see what it says.
> 
> ok. so it is too late to check since I already rebooted the OS?

Yeap, too late, if the root filesystem goes RO it does not leave any tracks 
except in dmesg.

I have seen the RO remount a number of times on lots of different HW/kernel/dist 
combinations, it is can be any number of issues, from a real hardware issue, a 
hardware driver issue, a filesystem driver issue, a bios issue, a main kernel 
issue, ... it has a lot of causes.

If it happens again, type "dmesg" and if possible save it someplace that it not 
readonly (type sync a few times to make sure it gets saved-or put it on a flash 
driver and if you have another device verify you have it), and then reboot.

                                   Roger




More information about the users mailing list