Tom Sightler wrote:
Vincent Cojot wrote:
Nice trick. Just one more thing: do we know if, when the fscked filesystem was
'modified', then the rc scripts will trap that and still 'reboot' the server (
if you have such a /etc/stsconfig/autofsck)? Answering yes automagically is
great but I 'd like to make sure the system reboots fine before entering
interactive if a filesystem was 'modified' by ad-hoc on-boot fsck.
The default behavior of rc.sysinit is to reboot if fsck returns an error
level of 2 or 3 (error level 2 from fsck means "System should be
rebooted" while error level 3 is the combination of error level 1 and 2
and means "File system errors corrected, system should be rebooted").
John Summerfield wrote:
You wouldn't want a boot loop either.
It's possible it could lead to a boot loop, but only in the case that
fsck thinks it fixed everything when it runs on every boot, but then
really doesn't. If fsck exits with an error level of 4 or higher, which
I believe that it should if it knows it was unable to correct all of the
errors, then it will still dump to a prompt. I'm not saying a boot loop
couldn't happen, but I think it would be rare, especially assuming the
system is properly partitioned to be robust against major corruption.
I didn't mean to imply it was a perfect solution, but just wanted to
offer up an option that might be "good enough" and is free and easy to
I wasn't casting nasturtiums, just posting a warning of something that
is all too commonly overlooked when implementing a solution.
I have seen bootloops: this year, in Windows XP, and in Linux (Fedora).
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
