Managers, many thanks for your immediate responses to my problem, it
seems I mis-understood the metadb files in use and how it is all put
together, I have some learning to do.
The crucial file that had been overwritten was /etc/system, which
contains the locations of copies of the metadb, on other disks to allow
the system to function even if one metadb is corrupted.
I mis-understood the function of the /etc/opt/SUNWmd/md.tab, thinking it
was the only file to configure the metadb, however this file is just a
text based interface to the metadb configuration, not the actual
configuration.
As for the wisdom of using metadb to control root, everyone is so far
claiming no problem, however until I have done some further learning
then I will reserve judgment.
Thanks again.
The answers received follow the:
Original Question:
Managers.
I have just watched a supplier overwrite our /etc filesystem, and now it
will not boot, complaining about fsck inconsistencies.
Scenario
Sun E450 solaris 2.5.1
The system disk was under metadb control and mounts
/dev/dsk/md/d0
However now our metadb is incorrect having been overwritten by one from
another site.
I have attempted to restore from ufsdumps but it cannot write to /tmp
because the /swap device on my machine is different from the metadb on
the other.
I can bring it up single user, but the metadb still looks at ../md/d0
for root and thus won';t go any further.
Before I re-install from cdrom, can someone confirm that it is OK to
have root system disk under metadb control, I don't think it is however
the guy who set it up was a consultant from Sun so who's right?
Answers Received:
>From Ashish Pant
We have the root system disk mirrored using ODS. However, we have
multiple
metadb's on a lot of disks. (eg s7 of root systemdisk and other disks)
maybe I am not getting your question ? However, I would be interested
in
knowing the outcome. Please do post a Summary.
Appreciate your help
regards
Ashish
>From Roar Smith
Hi,
most of our servers have mirrored /, swap, /usr and /opt using DiskSuite
version 4.0 or 4.1 (and /opt is translogged as well) with no problems!
If someone *zapped* your /etc directory, you will have lost the entries
in /etc/system which point at the Metadevice State Database Replicas.
These entries looke like this (actual entries depend on your mddb
config):
* Begin MDD database info (do not edit)
set md:mddb_bootlist1="sd:7:16 sd:7:1050 sd:7:2084 sd:15:16 sd:15:1050"
set md:mddb_bootlist2="sd:15:2084"
* End MDD database info (do not edit)
If you have the old configuration available in hardcopy somewhere, you
might be able to scratch the configuration by running "metadb -d
<device>"
on any existing replicas, and running metaroot to un-mirror your root
partition, and then boot and start over.
You may have to re-mount your root filesystem as read/write in order to
change anything at all: mount -o remount /dev/dsk/c0t0d0s0 /
(or whatever your root disk is called)
Regards,
>From Tom Vayda
Unless I am missing something, you are referring to ODS.
I can't answer everything but:
OK to include root in the metadbs but you should have multiples of these
on every disk. Make a small slice (10MB is more than you need) on each
disk and put multiple copies on each slice. Each metadb contains all
the state info. If you have multiples and one goes bad, which they do,
no problem.
Why your metadb was in etc is beyond me. What is in etc that is vital
is /etc/system. This has entries that must exist for ODS.
I would mv all the ODS startup scripts in /etc/rc*, then restore what
you need, then mv them back and pray. You'll probably need to do some
resyncs while you are at it.
Good luck,
>From Patrick Shannon
I'm very familiar with DiskSuite. From your message, I'm a bit unclear
about the exact nature of your problem. Clearly your system will not
boot,
but the metadb and /etc references don't jive.
/etc/system contains informatiion used by the OS to boot (the location
of the metadbs on disk and the root fs.).
The metadbs aren't located in /etc--at least not that I've ever seen.
It sounds to me like /etc/system was overwritten and now the OS can't
figure
out where the metadbs are located.
How about restoring the last backup of /etc/system and then
moving it to /etc?
Hope I didn't misunderstand your message,
Patrick
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:40 CDT