The consensus is unanimous that the 4.1.3 install process will
not newfs-trash a disk which has not been explicitly mentioned
in the install set-up process. There was a split opinion as to
whether specifying a disk without indicating "y" or "n" preservation
action would cause a newfs or not. Since /etc/install shows that
a newfs was run, it appears that some form of pilot-error did occur.
The good news is that a working level 0 dump tape was found and they
only lost a few weeks of work...since nobody has any good tricks for
recovering from a newfs-ed disk.
Thanks to the early respondants below, and any others that may come in:
len@netsys.com (Len Rose)
Eckhard.Rueggeberg@ts.go.dlr.de (Eckhard Rueggeberg)
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
kumeda@tds.com (Andy Kumeda)
poffen@san-jose.ate.slb.com (Russ Poffenberger)
pburyk@leis.leis.bellcore.com (Patrick Buryk)
Mike Raffety <mike_raffety@il.us.swissbank.com>
danny@ews7.dseg.ti.com (Danny Johnson)
Original posting:
A friend of mine called to report the following situation:
A Sparc 2 with one internal disk (sd0) and one external disk (sd3)
did a full install of 4.1.3
They specified that /, /usr, and /home on sd0 were all to be modified
by the install process.
(Unwisely), they did not power down or disconnect sd3. In the install
process they did not supply any information whatsoever about sd3, which
had one user partition (sd3c).
After the successful and uneventful installation, they modified /etc/fstab
and mounted sd3c without incident, but it now appears that a newfs had been
run during the install process and all user files were lost. Of course, they
then found out that their backups were inadequate...
1) Can anybody confirm that the 4.1.3 install would indeed newfs the c partitionof a disk that it found attached but which had not been specified in the
install set-up process?
2) I am not aware of their being any realistic chances of recovering a disk
full of data after a newfs has been run. These folks aren't up to doing adb
on raw disk partitions or anything like that. If anybody has any good voodoo
that is known to work in these situations, please let me know.
Tom Slezak
Human Genome Center, L-452
Lawrence Livermore National Lab
7000 East Ave. Livermore, CA 94550
email: slezak@llnl.gov (tom@yac.llnl.gov)
phone: (510) 422-5746 fax: (510) 423-3608
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:03 CDT