Mike,
What we do is make a copy of the fstab whenever we make a successful
change. The base install
fstab is saved as /etc/fstab.sav00. Each time we make a change, we save
it again under the next
sequential number-/etc/fstab.sav01. If fstab is corrupted, usually we
can get / to mount, so we
can copy the last known good fstab.savxx back to fstab. If we cannot,
then we boot the install
cds to perform this copy. Having the fstab.sav00 is really handy. It
just mounts the base operating
system. If your user application is what is having problems, you can
get your operating system
up and go fix the user application files.
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?
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.)?
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
----------------------------------------------------------------------
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
