Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Recovering logical partitions from a failed GhostBSD install

If none of the specific sub-forums seem right for your thread, ask here.
Post Reply
Message
Author
User avatar
cofi
Posts: 13
Joined: 2014-10-23 21:34

Recovering logical partitions from a failed GhostBSD install

#1 Post by cofi »

Hi,

In a rush, I've made a dumb mistake of trying to install GhostBSD on an logical partition. :oops: Luckily or not, install failed due to bad DVD.

Anyhow, following a reboot all logical partitions are seemingly still there ( as found by testdisk ), though ( obviously ) inaccessible from Debian.

fdisk:

Code: Select all

Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xcb5cb31b

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1  *         2048     206847     204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2          206848  209922047  209715200   100G  7 HPFS/NTFS/exFAT
/dev/sda3       209922048  461580287  251658240   120G 83 Linux
/dev/sda4       461582334 1953523711 1491941378 711,4G a5 FreeBSD

Partition 4 does not start on physical sector boundary.
testdisk:

Code: Select all

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63

     Partition                  Start        End    Size in sectors

 1 * HPFS - NTFS              0  32 33    12 223 19     204800
 2 P HPFS - NTFS             12 223 20 13067  10 63  209715200
 3 P Linux                13067  11  1 28732  11 15  251658240 [Stretch]
 4 E extended LBA         28732  11 16 121601  57 56 1491943424
 5 L FreeBSD              28732  43 46 15665   0 16 36028796809039875
 6 L Linux                29776 161 18 45441 161 32  251658240
 7 L Linux                45441 194  2 53274  66 40  125829120 [Jessie]
 8 L Linux                53274  99 10 57190 162 60   62914560 [Neon]
 9 L Linux                57190 195 30 61107   4 17   62914560 [Salix]
10 L Linux                61107  36 50 65023 100 37   62914560
11 L Linux                65023 133  7 68939 196 57   62914560 [Arch]
12 L Linux                68939 229 27 110713  60  3  671088640 [T-Store]
13 L HPFS - NTFS          110713  92 36 121601  57 56  174913536











>[  Quit  ]  [Deeper Search]  [ Write  ]
                              Return to main menu
Screenshot of the above, inluding GParted:
http://i.imgur.com/Tge4U0f.png

Drive is a 1TB, MBR partitioned SATA disk. Main system is Debian Stretch, installed on the same drive, on /dev/sda3.

I haven't done nor tried anything yet, or in other words, excluding GhostBSD installer nothing has touched the extended/logical partition(s).
If memory serves me well, GhostBSD was to go on /dev/sda6 ( or ada0s4a in BSD parlance ), using UFS+SUJ as fs.

This is my first time in a specific mess like this, so any pointers as to what is the best course of action towards recovery would be greatly apreciated!
The only ( likely bad ) idea that comes to my mind is to change the type of BSD partition back to "Extended"... :?

EDIT:

I do have a spare drive ready to use should it be needed ( smaller though, 640GB ).

lostfarmer
Posts: 19
Joined: 2016-05-07 01:13
Location: Idaho

Re: Recovering logical partitions from a failed GhostBSD ins

#2 Post by lostfarmer »

best course of action towards recovery
recovery of what exactly ? Looking at the testdisk output #1-#4 good, #6-#13 good as far as the partition table go's, #5-bad. If you want to recover the #'s I listed as good, then use testdisk and select them as you posted and write to disk. If you want what was on #5 then that will be more difficult if even able to do ( do not do anything). IF you want #5 , what file system was it ? What size was it. #5 freebsd ends at a sector before it starts. (example - start at sector 2000 and ends at sector 1000, not possible)

We do need to know just what you are recovering , before you proceed. Have you booted into any of the first 3 primary partitions ? or are you booting with a live linux ?

User avatar
cofi
Posts: 13
Joined: 2014-10-23 21:34

#3 Post by cofi »

@lostfarmer:
Thanks for the reply, much appreciated!
We do need to know just what you are recovering , before you proceed. Have you booted into any of the first 3 primary partitions ? or are you booting with a live linux ?
Well, indeed. :D
Sorry though, it just goes to prove for a bilionth time that one is really better off not messing with his system/disks nor asking for support in a rush, while being dead tired. :roll: :oops:

Yes, I have booted Debian from third partition. As shown by fdisk and GParted in a screenshot^ first 3 partitions are visible and accessible.
lostfarmer wrote:
best course of action towards recovery
recovery of what exactly ? Looking at the testdisk output #1-#4 good, #6-#13 good as far as the partition table go's, #5-bad. If you want to recover the #'s I listed as good, then use testdisk and select them as you posted and write to disk. If you want what was on #5 then that will be more difficult if even able to do ( do not do anything). IF you want #5 , what file system was it ? What size was it. #5 freebsd ends at a sector before it starts. (example - start at sector 2000 and ends at sector 1000, not possible)
I don't care much for #5. It was destined for BSD anyway, thus expandable. Before install attempt it was empty ext4, 120GB in size.
During installation I just selected it, formated with UFS+SUJ & hit install.
I certanly can boot GhostBSD live to check how things look from there, but I'm not really sure if that is a good idea ( automount, fsck etc. )?

@recovery:

I need to recover #6-13, with #12 & #13 being the most important. All of them are ext4, except the #13 ( NTFS ).

What actually confuses me is why are partitions #6 and later invisible to Debian in the first place? Taking into account the fact that BSD uses slices/sub-partitions still doesn't "explain" it to me... :roll:
lostfarmer wrote:If you want to recover the #'s I listed as good, then use testdisk and select them as you posted and write to disk.
Are you sure?
To rephrase that, with the things as they are, I assume that almost certanly data can be "extracted" out as the last resort ( eg. with dd ), but I'm not sure what would be the worse outcome of writing with testdisk, regarding to data? :?

lostfarmer
Posts: 19
Joined: 2016-05-07 01:13
Location: Idaho

Re: Recovering logical partitions from a failed GhostBSD ins

#4 Post by lostfarmer »

when you run 'testdisk' and select 'analyse' , where your partitions were listed, there is an option "P" to list files when you select a partition . Does it correctly list the files on # 6 to #13 ? If yes , it should be good to write the the partition table to disk with the # 5 deleted or not selected (you do not want it listed as a partition). All testdisk should do is write a new partition table to the MBR and the needed extended partition tables which will be outside of the partitions sectors and its data.

IF the data is very important , do a 'dd' copy of hdd first or at lest all sectors to end of hdd after the ending sector of sda3 [(461580287+1 ) to last sector 1953525168].


Note-- 10 or so years ago testdisk was good, now I do have problems with it correctly detecting partitions.
What actually confuses me is why are partitions #6 and later invisible to Debian in the first place? Taking into account the fact that BSD uses slices/sub-partitions still doesn't "explain" it to me
The primary partition table was modified and the '4 E extended LBA ' entrie was deleted there by removing all extended partition information. Each extended partition has its own extended partition table and they are daisy chained , one to the next, if the one extended partition table is incorrectly deleted all later are lost.
while being dead tired
that is me now so will close.

User avatar
cofi
Posts: 13
Joined: 2014-10-23 21:34

Re: Recovering logical partitions from a failed GhostBSD ins

#5 Post by cofi »

Done, all good! :lol:

Did the "dd" backup and for a good measure manual extracting of the most important stuff via testdisk, deleted the BSD partition & wrote.
Following a reboot, got the greeting from Audacious playing music from sda11. :D :D

I still need to check the sda5-10 ( boot from them actually ) & sda12, but if it's any indication, data on sda11 is fine and fsck on it runs clean.

Code: Select all

[root@stretch-K10][/]# fdisk -l /dev/sda
Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xcb5cb31b

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1  *          2048     206847     204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2           206848  209922047  209715200   100G  7 HPFS/NTFS/exFAT
/dev/sda3        209922048  461580287  251658240   120G 83 Linux
/dev/sda4        461580288 1953523711 1491943424 711,4G  f W95 Ext'd (LBA)
/dev/sda5        478361600  730019839  251658240   120G 83 Linux
/dev/sda6        730021888  855851007  125829120    60G 83 Linux
/dev/sda7        855853056  918767615   62914560    30G 83 Linux
/dev/sda8        918769664  981684223   62914560    30G 83 Linux
/dev/sda9        981686272 1044600831   62914560    30G 83 Linux
/dev/sda10      1044602880 1107517439   62914560    30G 83 Linux
/dev/sda11      1107519488 1778608127  671088640   320G 83 Linux
/dev/sda12      1778610176 1953523711  174913536  83,4G  7 HPFS/NTFS/exFAT
The only issue is 8 gigs of unallocated space as seen by GParted before the first logical partition ( screen: http://i.imgur.com/mGahFHm.png ).
I say issue, because sda5 and following partitions seem to have the exact same size as before, so one of them has to be nipped ( sda5 presumably )...
Anyway, with the important data & stuff on 11 & 12 back, that's the thing to investigate the other day.

@lostfarmer:
Again, many, many, thanks for your assistance and explanations!

Cheers! :)

User avatar
cofi
Posts: 13
Joined: 2014-10-23 21:34

Re: Recovering logical partitions from a failed GhostBSD ins

#6 Post by cofi »

cofi wrote:I still need to check the sda5-10 ( boot from them actually ) & sda12, but if it's any indication, data on sda11 is fine and fsck on it runs clean.
All fine!
cofi wrote:The only issue is 8 gigs of unallocated space as seen by GParted before the first logical partition ( screen: http://i.imgur.com/mGahFHm.png ).
I say issue, because sda5 and following partitions seem to have the exact same size as before, so one of them has to be nipped ( sda5 presumably )...
Anyway, with the important data & stuff on 11 & 12 back, that's the thing to investigate the other day.
It was the swap partiton taking those 8 gigs ( right, I did, by some luck, wrongly selected it for GhostBSD root ). :D :D :D

lostfarmer
Posts: 19
Joined: 2016-05-07 01:13
Location: Idaho

Re: Recovering logical partitions from a failed GhostBSD ins

#7 Post by lostfarmer »

have fun and be more careful next time. I do know how to mess up my installed OS's for sure.

Post Reply