Re: Finding superblocks, etc. (long)

2004-01-16 Thread Blars Blarson
In article [EMAIL PROTECTED] 
[EMAIL PROTECTED] writes:
I have a disk full of data and no way to reach the data because my
partitions are screwed.  If I could find my superblocks or my old
partition map I could probably salvage it at least a little, do
something about it, and I'm wondering if anyone can help.  Because it
involves issues with the Sun disklabel I believe it is sparc-specific.

The sun disklabel is stored in the first 512 bytes of the disk.  It
sounds like you will need to recreate this.  If you know how your disk
was set up, you can recreate it with fdisk, otherwise you could try
experimenting with guesses at what it was.  You may need to wipe the
label out with dd first.


Of course, when practical you should copy the entire disk with dd
before you try messing with it.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.



Finding superblocks, etc. (long)

2004-01-13 Thread Orion Buckminster Montoya
I will send a bottle of whisky (or your choice of beverage, or make a
charitable donation) to anyone who can help me fix this.

I have a disk full of data and no way to reach the data because my
partitions are screwed.  If I could find my superblocks or my old
partition map I could probably salvage it at least a little, do
something about it, and I'm wondering if anyone can help.  Because it
involves issues with the Sun disklabel I believe it is sparc-specific.

Running Woody on an Ultra 5, I formatted a 40GB Western Digital
Protege attached via firewire, and gave it a sun disklabel and the
same partitions I'd given the stock 9.1GB Seagate Barracuda when I
installed:
1: Boot
2: /
3: whole disk
4: swap
and 4 more, but I don't think that matters.

My fatal mistake may have been that I used dd to copy the boot
partition, hoping that this would make SILO just magically work -- I
did 

dd if=/dev/hda1 of=/dev/sda1

I don't think that the partition map should have been on *da1, but
that's the only explanation I can come up with.  After doing that I
mkfs.ext3'd the remaining data partitions (2, 5-8), mounted them, and
rsynced the old partitions to their new counterparts.  Everything
looked fine.  So I shut down, removed the old hard drive, put in the
new, and started up, but couldn't get past the S of SILO.  

When I booted from the Woody CD, I couldn't mount any of the
partitions, fsck couldn't do anything, and skipping ahead to backed-up
superblocks (i.e. fsck -f -b 16385) didn't do anything -- but by
lessing the raw devices, I saw that my data were on the drive, looked
fine and healthy, just not mountable.

All my rsynced data are on the disk, across some 10GB or so of new
partitioned space.  My new disk's partitions tend to be a little
larger than the old ones, but the bulk of the extra 31GB is in the
last partition.  But since the new disk with the new, larger
partitions somehow has the old partition map, the boundaries of the
partitions are in the wrong places, so I can't find the superblocks
and don't really know what I would do with them if I could.

And now when I try to reformat the new disk, fdisk tries to make it
something around 6-7 GB in size, and after that first partitioning I
can no longer convince it that it's dealing with a full 40GB.  But I
have the identical drive on an identical machine (Woody/Ultra5) with
no problem at all.

Then I made a couple of really stupid mistakes and blew away my /usr/
and /var/ on the old disk, so I've lost my old cgi-bin and /var/www/,
so I have no way to get back my old system.

So does anyone have any theoretical advice on recovering overwritten
partition maps, whether partition maps are backed anywhere on disk, or
finding superblocks?

I hope my length has not repelled the helpful knowledgable people.

Thanks,

O.



Re: Finding superblocks, etc. (long)

2004-01-13 Thread Tad Bilby
 I will send a bottle of whisky (or your choice of beverage, or make a
 charitable donation) to anyone who can help me fix this.
GlenFiddich
http://world.glenfiddich.com/enjoy/range/whisky_range/special_res.html
:-)
 And now when I try to reformat the new disk, fdisk tries to make it
 something around 6-7 GB in size, and after that first partitioning I
 can no longer convince it that it's dealing with a full 40GB.  But I
 have the identical drive on an identical machine (Woody/Ultra5) with no
 problem at all.
You probably have a pre 3.31 Ultra 5/10 OpenBoot PROM on the affected
system.  Flash it with this patch to see larger than 7GB with IDE:
http://sunsolve.sun.com
Patch-ID# 106121-18
You will need a hard disk with bootable Solaris to be able boot the patch
file.
 Thanks,

 O.