battle@alphard.cs.utk.edu (David Battle) (12/07/89)
We have a Trimarchi Datastaion 600 disk with a botched partition table. It is mounted on a DECStation 3100. I have reason to believe that the data on the various partitions may still be valid, but it's hard to be sure without a correct partition table. Does anyone know any way (simple or arcane) to recover the partition table on a disk such as this? -David L. Battle battle@battle.esd.ornl.gov battle@utkux1.utk.edu
battle@alphard.cs.utk.edu (David Battle) (12/07/89)
In article <1483@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >We have a Trimarchi Datastaion 600 disk with a botched partition table. >It is mounted on a DECStation 3100. > >I have reason to believe that the data on the various partitions may still >be valid, but it's hard to be sure without a correct partition table. > >Does anyone know any way (simple or arcane) to recover the partition table >on a disk such as this? > > -David L. Battle > battle@battle.esd.ornl.gov > battle@utkux1.utk.edu Well, I answered my own question this time. The answer is "yes it can be done" because I just did it. Basicly what I did was tried to remember how I had parititioned it, then tried various guesses by using chpt followed by fsck -n on the partition whose bounds I was guessing (the -n flag makes sure fsck doesn't try to write on the partition if it isn't right). It only took a few tries before I had guessed the first partition, and it went pretty smoothly from there because all of the partitions were contiguous (and a couple of them (I remembered) were the exact same size). The problem appears to have been that the "b" partition started at the very beginning of the disk (the "a" partition was 0 length) but the partition table is normally stored at the beginning of the "a" partition (isn't it?). Thus we had no problems until we decided to make that particular "b" partition an alternate swap partition. Once we started swapping on "b", everything was *still* hunky dory until I rebooted and tried to remount the other partitions on that disk. Only then did the file system notice that the partition table was missing (it had been over written by swapping activity). -David L. Battle battle@battle.esd.ornl.gov battle@utkux1.utk.edu
chris@mimsy.umd.edu (Chris Torek) (12/07/89)
In article <1485@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >The problem appears to have been that the "b" partition started at the very >beginning of the disk (the "a" partition was 0 length) but the partition table >is normally stored at the beginning of the "a" partition (isn't it?). Ultrix (and only Ultrix) stores the partition table in the super-block area. Of course, this assumes there *is* a super-block area at the beginning of the disk. 4BSD (sufficiently recent versions) and SunOS both put the label in block zero, and put the partition table in the label. 4BSD (but not SunOS, or older versions thereof, at least) also allows swapping on the region containing the label (it avoids stepping on sector 0, whether the disk is labelled or not). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris