/etc/fstab doesn't get changed very often - generally, only when
adding/removing storage. Despite your incident, its damage a low-risk
event, and I can't imagine how it might have happened other than by
human mistake.
Actually I have had YaST corrupt the fstab. This was in the early
SLES9 days.
Ron Foster
Mike Walter wrote:
At one point one of our "zLinux" (marketing and politically incorrect)
Proof of Concept servers suffered some form of filesystem
corruption. The
fstab was severely wounded, requiring that it be manually rebuilt by
hand.
During the rebuild period, the server was out of commission.
Since the fstab is so critical to boot a Linux server, I can't help but
wonder if it would make sense to display the fstab (and perhaps some
other
critical, but not too large) files to the VM SPOOLed console log upon
successful completion of each boot. That way, if the critical files are
corrupt at one boot time, one only needs to look back through the VM
console log (which requires no perhaps-unavailable Linux server
tools) for
the previous successful boot. (I am intentionally avoiding Linux's own
syslog as a review/copy source since it may not be available if
something
critical had been corrupted).
At that point one could compare what's in the current/corrupted file to
the last good copy from the last good console log, and with fix the bad
file, or copy/paste the entire good file in place of the bad one (hence
the need for the "critical" files to be relatively short).
So... the questions are:
1) Does that make sense to do?
Not to my mind. If there's a corrupted file, would you rather it be
/etc/fstab, or your customer database?
Filesystem corruption leading to damaged files is pretty rare. I _can_
imagine damaged files (data in buffers is unwritten) after a disorderly
shutdown, but I don't recall seeing evidence of that even.
2) What's the best way to echo/cat the critical files to the VM SPOOLed
console log after every successful boot?
3) Is there a better way (without access to file-level backups, which we
don't have yet during a P.O.C.)?
/etc/fstab doesn't get changed very often - generally, only when
adding/removing storage. Despite your incident, its damage a low-risk
event, and I can't imagine how it might have happened other than by
human mistake.
That said, something on my RHEL-clone system seems to be touching it on
boot.
--
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:-)
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
