Lost whole disk while upgrading from 7.0 to 9.0

Ajax

Ajax

Have been running 7.0-REL and decided to upgrade to 9.0-REL. Used freebsd-update as per manual, all went successfully but after reboot got message about inability to load / partition! Mounted disk to another FreeBSD and what I see! — old GPT map (disk used to be part of iMac) is "activated"!
Code: 
=>       34  976773101  da0  GPT  (465G)
         34          6       - free -  (3.0k)
         40     409600    1  efi  (200M)
     409640  976101344    2  apple-hfs  (465G)
  976510984     262151       - free -  (128M)
Okay, I though, if this is THAT bad, will try to connect onto iMac. But there I got opposite picture
Code: 
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk1
   1:                    FreeBSD                         500.1 GB   disk1s1
But disk used to have one "old-style" slice and few partitions, now I'm left with the disk which cannot be mounted in either OS X or FreeBSD. Any ideas how to restore the data? I can boot from the disk but nothing goes further. Looks like there are GPT and MBR present on the disk but version 9 tried to use GPT first, any chances I can disable this?
 
Now this looks a bit better — mounted disk onto virtual FreeBSD 7 and got proper partitions displayed. So, the problem is that disk has Hybrid MBR/GPT shame and while FreeBSD tended to use MBR part, version 9 want to use GPT. If there is any way to "disable" GPT in the version 9, at least until I could boot from old plain MBR slice?
 
I am a creative and therefore destructive sort of character, so if it was me, I would back up the disk, then figure out the correct partition starts and ends, and create a new GPT slice that matches those numbers.

Unfortunately, I've never done this... but it is theoretically possible. The hard part is knowing what to calculate.

And if you do it wrong, things get very broken. This is why you absolutely must have a backup.


I don't understand your iMAC output (which has no numbers for slice start sectors, which you need), but if it was gpt inside gpt, I mean to take:

Code: 
=>       34  976773101  da0  GPT  (465G)
         34          6       - free -  (3.0k)
         40     409600    1  efi  (200M)
     409640  976101344    2  apple-hfs  (465G)
  976510984     262151       - free -  (128M)

=>       34  976773101  da0p2  GPT  (465G)
         34          6         - free -  (3.0k)
         64  976101000      1  freebsd-ufs  (465G)
(above numbers made up and may not make sense)

And then add the start of the da0's slice2 (409640) and add it to the offset of da0p2's slice 1 (64), to turn it into:

409655+64 = 409719

Then destroy all slices and create a new slice (using "-a 1" so it doesn't try to auto align it to 63 sectors or whatever it normally does):

# gpart add -a 1 -b 409719 -t freebsd-ufs -l labelgoeshere da0

Code: 
=>       34  976773101  da0  GPT  (465G)
         34          6         - free -  (3.0k)
     409719  976101000      1  freebsd-ufs  (465G)

And then DO NOT format, and then just mount it read only and see what happens. If it works, mount it rw.

And an obvious side effect is: any OS that depended on the old structure of the disk will no longer be able to use it.



And the less destructive and therefore less fun method would be to just find a system that will mount it, mount it there, then put a new disk in the destination machine booted in some other way (eg. new install on a USB stick or live DVD), and copy the files over the network.
 
Well, fdisk under OS X gave me more info.
Code: 
ajax-mbp:~ ajax$ fdisk /dev/disk1
Disk: /dev/disk1	geometry: 60801/255/63 [976773168 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
*1: A5    0   1   1 - 1023 254  63 [        63 -  976768002] FreeBSD     
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
However, there is the interesting stuff: why does FreeBSD 7 load MBR scheme in front of GPT (see below) and how do I force version 9 (or 8) to do the same?

Here is I tried to boot from the disk (so into 9.0-REL). As you can see there is no /dev/ad4s1 at all while available records leads to nowhere.
Screen%20Shot%202012-02-15%20at%2014.14.32.png

And here what I can see on the disk which is connected onto 7.4-REL machine — slice 1 present as well as its "parts" a to h.
Screen%20Shot%202012-02-15%20at%2014.25.46.png
 
You must log in or register to reply here.
Back
Top