Jump to content

How screwed am I? (Partition Problem)


Recommended Posts

I was resizing a partition on one of my laptops to make room for an Ubuntu installation using Partition Wizard. when PW finished, I restarted my Pc and the installation of W7 that was on the partition that I shrunk bluescreened while showing the Startung Windows... screen. The other OS on the drive is fine. When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

The only problem is that this is on an OCZ Vertex 4 so would I be able to use traditional recovery software or not?

Link to comment
Share on other sites


Which "other" OS?

First thing you should do, in any case, is to make a "forensic sound" or "dd-like" image of the disk (you will need a slightly larger disk) or make a "clone" (you will need a "same size" disk.

If the "other OS" (or the PE/liveCD/whatever) you are going to boot does not send automagically the TRIM command, there should be no differences (I believe that the OCZ has not an "automatic garbage collector", but even if it has, it should be about "deleted" files and not about a partiion that became RAW) from a "normal" hard disk recovery.

jaclaz

Link to comment
Share on other sites

Which "other" OS?

First thing you should do, in any case, is to make a "forensic sound" or "dd-like" image of the disk (you will need a slightly larger disk) or make a "clone" (you will need a "same size" disk.

If the "other OS" (or the PE/liveCD/whatever) you are going to boot does not send automagically the TRIM command, there should be no differences (I believe that the OCZ has not an "automatic garbage collector", but even if it has, it should be about "deleted" files and not about a partiion that became RAW) from a "normal" hard disk recovery.

jaclaz

The other OS is Windows 7 x86. A check of disabledeletenotify shows that TRIM seems to be enabled but since TRIM is for just files and this OS didn't come in contact with the other partition before the partition got changed into that Unalloc\Raw mix, wouldn't that mean that TRIM can't do anything?

Also, since I'm currently away from home, I don't have any drives that are large enough (I do have one, but it is half full with data that wouldn't fit elsewhere).

I may be asking this question slightly too early, but if I get what seems like all of the data off my drive (since with SSDs, it most probably would be all or nothing), would it be better to try and recreate the OS using that or just reinstall and dump the data?

Edited by Torchizard
Link to comment
Share on other sites

The point is that right now you have provided some symptoms only.

We need to make a diagnosis instead to say what may happen (with any degree of accuracy).

It is well possible that by just correcting a bunch of bytes you can restore the volume exactly as it was :) or it is possible that you cannot recover any data of any kind :(.

We have to understand what happened first thing.

The point of copying the data to another disk is - besides good practice and "common sense" - in this particular case that of making sure that no TRIM or actually "garbage collection" happens.

The generic risk when doing data recovery (no matter if on a SSD or an hard disk) is that attempting a given approach, this approach may make a subsequent different approach impossible (or not working, while it may have worked if the earlier attempt was not made), having a "forensic sound" image allows one to be able to re-start form scratch at will.

jaclaz

Link to comment
Share on other sites

The point of copying the data to another disk is - besides good practice and "common sense" - in this particular case that of making sure that no TRIM or actually "garbage collection" happens.

The generic risk when doing data recovery (no matter if on a SSD or an hard disk) is that attempting a given approach, this approach may make a subsequent different approach impossible (or not working, while it may have worked if the earlier attempt was not made), having a "forensic sound" image allows one to be able to re-start form scratch at will.

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.

Link to comment
Share on other sites

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.

I do understand that, but I have to tell you the reason why it was suggested and the risk that you may face by being not able to follow that advice.

So, next step is to get and run TESTDISK, to have hopefully a general idea of the issue.

You want to create a LOG and to post it as an attachment to your next reply.

http://www.cgsecurity.org/wiki/TestDisk

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

When asked if you want to look for partitions created under Vista, answer Yes.

DO NOT, and I mean DO NOT take any action unless you are VERY, VERY sure about what you are doing before having posted the LOG and having got a reply with possible diagnosis/set of recovery instructions.

jaclaz

Link to comment
Share on other sites

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.

I do understand that, but I have to tell you the reason why it was suggested and the risk that you may face by being not able to follow that advice.

So, next step is to get and run TESTDISK, to have hopefully a general idea of the issue.

You want to create a LOG and to post it as an attachment to your next reply.

http://www.cgsecurity.org/wiki/TestDisk

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

When asked if you want to look for partitions created under Vista, answer Yes.

DO NOT, and I mean DO NOT take any action unless you are VERY, VERY sure about what you are doing before having posted the LOG and having got a reply with possible diagnosis/set of recovery instructions.

jaclaz

So I used TestDisk and it seems to have found the partition. When I select it, it also seems to show all the folders\files that were on there before. It didn't ask me about vista partitions but it still showed the partition.

I don't see the option to upload files anywhere on here so here's a Pastebin link instead: http://pastebin.com/3FEHRDnx

Link to comment
Share on other sites

Good :).

It seems a "plain" MBR partition table corruption error.

This is what your disk looks like:

Analyse Disk /dev/sda - 512 GB / 476 GiB - CHS 62260 255 63

Geometry from i386 MBR: head=255 sector=63

NTFS at 0/32/33

NTFS at 1839/242/4

Info: size boot_sector 663453689, partition 663453696

NTFS at 49512/34/59

Current partition structure:

1 * HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

2 P HPFS - NTFS 1839 242 4 43138 8 6 663453696

3 P HPFS - NTFS 49512 34 59 62260 88 36 204800000

And this is how it should look (according to TESTDISK):

Results

* HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

NTFS, blocksize=4096, 104 MB / 100 MiB

P HPFS - NTFS 12 223 20 49512 34 58 795205632

NTFS, blocksize=4096, 407 GB / 379 GiB

P HPFS - NTFS 49512 34 59 62260 88 36 204800000

NTFS, blocksize=4096, 104 GB / 97 GiBinterface_write()

1 * HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

2 P HPFS - NTFS 12 223 20 49512 34 58 795205632

3 P HPFS - NTFS 49512 34 59 62260 88 36 204800000

simulate write!

The first and last partitions appear the same (and correct).

The one in the middle does not.

If by accessing it through TESTDISK with the "simulated written" new partition table you can actually see it's contents (directories/files) it should mean that the whatever you used to resize the "middle" partition did not do it's job or was interrupted before updating the partition table.

The partitioning that TESTDISK found appears correct. :)

Now, it's up to you.

You can decide to first save the data (only the really meaningful one, i.e. something that you really-really cannot replace/reinstall/recreate) by copying the files from the disk through the TESTDISK (temporary/volatile) access through the "p" (of course these files need to be copied to another disk drive) manually.

And after re-run testdisk (append to the log, just in case) and repeat the analysis then write the changes:

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step#Partition_table_recovery

Or directly do the writing of the correct partition table.

In any case, the first thing that will be needed, after the new partition table is written and a reboot, would be a CHKDSK on the volume.

BUT there is something "queer" (that needs to be cleared) BEFORE doing anything of the above.

You reported:

When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

What you will have after writing the partition table will be:

100 Mb System partition Primary (like you have now) 204800x512=104857600

400 Gb partition Primary 795205632x512=407145283584

100 Gb partition Primary 204800000x512=104857600000

that would be the same as you had before even attempting to shrink the middle partition.

even if the "roughly" 100 Gb last partition corresponds to the 90 Gb one you saw, the math doesn't sound right, 14+300+50, even roughly, does not match the current 400 Gb (which instead sounds right).

The last partition is 104,857,600,000, i.e. around 100 or 98 Gb (depending on how it is measured)

In the "current" setup the "gap" between first and second partition is 15,028,191,232 bytes (which would correspond to the 14 Gb you saw), the "middle" (wrong) partition is 339,688,292,352 (which would be seen as a 316 or 324 Gb partition) and the "gap" before the last partition is 52,428,800,000, i.e. seen as 50 Gb.

Is it possible that you reported 300 instead of 316 or 324?

Compare with the table:

jaclaz

Heck the table cannot be attached, find it here:

http://www2.zshares.net/lu50vdy9cz84

Edited by jaclaz
Link to comment
Share on other sites

Good :).

It seems a "plain" MBR partition table corruption error.

This is what your disk looks like:

Analyse Disk /dev/sda - 512 GB / 476 GiB - CHS 62260 255 63

Geometry from i386 MBR: head=255 sector=63

NTFS at 0/32/33

NTFS at 1839/242/4

Info: size boot_sector 663453689, partition 663453696

NTFS at 49512/34/59

Current partition structure:

1 * HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

2 P HPFS - NTFS 1839 242 4 43138 8 6 663453696

3 P HPFS - NTFS 49512 34 59 62260 88 36 204800000

And this is how it should look (according to TESTDISK):

Results

* HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

NTFS, blocksize=4096, 104 MB / 100 MiB

P HPFS - NTFS 12 223 20 49512 34 58 795205632

NTFS, blocksize=4096, 407 GB / 379 GiB

P HPFS - NTFS 49512 34 59 62260 88 36 204800000

NTFS, blocksize=4096, 104 GB / 97 GiBinterface_write()

1 * HPFS - NTFS 0 32 33 12 223 19 204800 [system Reserved]

2 P HPFS - NTFS 12 223 20 49512 34 58 795205632

3 P HPFS - NTFS 49512 34 59 62260 88 36 204800000

simulate write!

The first and last partitions appear the same (and correct).

The one in the middle does not.

If by accessing it through TESTDISK with the "simulated written" new partition table you can actually see it's contents (directories/files) it should mean that the whatever you used to resize the "middle" partition did not do it's job or was interrupted before updating the partition table.

The partitioning that TESTDISK found appears correct. :)

Now, it's up to you.

You can decide to first save the data (only the really meaningful one, i.e. something that you really-really cannot replace/reinstall/recreate) by copying the files from the disk through the TESTDISK (temporary/volatile) access through the "p" (of course these files need to be copied to another disk drive) manually.

And after re-run testdisk (append to the log, just in case) and repeat the analysis then write the changes:

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step#Partition_table_recovery

Or directly do the writing of the correct partition table.

In any case, the first thing that will be needed, after the new partition table is written and a reboot, would be a CHKDSK on the volume.

BUT there is something "queer" (that needs to be cleared) BEFORE doing anything of the above.

You reported:

When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

What you will have after writing the partition table will be:

100 Mb System partition Primary (like you have now) 204800x512=104857600

400 Gb partition Primary 795205632x512=407145283584

100 Gb partition Primary 204800000x512=104857600000

that would be the same as you had before even attempting to shrink the middle partition.

even if the "roughly" 100 Gb last partition corresponds to the 90 Gb one you saw, the math doesn't sound right, 14+300+50, even roughly, does not match the current 400 Gb (which instead sounds right).

The last partition is 104,857,600,000, i.e. around 100 or 98 Gb (depending on how it is measured)

In the "current" setup the "gap" between first and second partition is 15,028,191,232 bytes (which would correspond to the 14 Gb you saw), the "middle" (wrong) partition is 339,688,292,352 (which would be seen as a 316 or 324 Gb partition) and the "gap" before the last partition is 52,428,800,000, i.e. seen as 50 Gb.

Is it possible that you reported 300 instead of 316 or 324?

Compare with the table:

jaclaz

Heck the table cannot be attached, find it here:

http://www2.zshares.net/lu50vdy9cz84

Yeah, the values that I said were only rough estimates, based only on the first digit.

What it actually reports is:

100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)

Link to comment
Share on other sites

[Off-Topic] Sorry to interrupt, but... both of you are not being able to attach to this thread, because the full editor in not offering the "Attach Files" interface? If so, let me know and I'll try to get it fixed fast, because that sure is serious... [/Off-Topic]

Link to comment
Share on other sites

[Off-Topic] Sorry to interrupt, but... both of you are not being able to attach to this thread, because the full editor in not offering the "Attach Files" interface? If so, let me know and I'll try to get it fixed fast, because that sure is serious... [/Off-Topic]

Yeah, on one of my previous topics I attached a file and now when I was looking for the attach button, I spent five minutes trying to find something which I previously remembered existing.

[Offtopic] My post number is now the meaning of life! [/Offtopic]

Edited by Torchizard
Link to comment
Share on other sites

Yeah, the values that I said were only rough estimates, based only on the first digit.

....

What it actually reports is:

100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)

Good. :) Everything seems fine then, maybe excepted to the meaning of life of the verbs "to round" and to "approximate". ;)

And in any case that is the answer to the ultimate question about life, the universe an everything, not about the meaning of liff of life, which it's nothing much special:

http://www.imdb.com/title/tt0085959/quotes?item=qt0256724

M-hmm. Well, it's nothing very special. Uh, try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations.

:yes:

@dencorso

What I see below Attach Files

Attach This File You can upload up to Uploading is not allowed of files (Max. single file size: 100MB)

And NO :no:

Try our advanced uploader (requires Flash 9)

I am not even THINKING of trying the advanced uploader (what i call "retarded flash based bloat" ;))

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Yeah, the values that I said were only rough estimates, based only on the first digit.

....

What it actually reports is:

100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)

Good. :) Everything seems fine then, maybe excepted to the meaning of life of the verbs "to round" and to "approximate". ;)

And in any case that is the answer to the ultimate question about life, the universe an everything, not about the meaning of liff of life, which it's nothing much special:

http://www.imdb.com/title/tt0085959/quotes?item=qt0256724

M-hmm. Well, it's nothing very special. Uh, try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations.

:yes:

@dencorso

What I see below Attach Files

Attach This File You can upload up to Uploading is not allowed of files (Max. single file size: 100MB)

And NO :no:

Try our advanced uploader (requires Flash 9)

I am not even THINKING of trying the advanced uploader (what i call "retarded flash based bloat" ;))

jaclaz

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?

Link to comment
Share on other sites

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?

Yes and no. :w00t:

Meaning that with 99% of probabilities, since you can see your files in the "simulated" partition scheme that TESTDISK found, it should mean that the filesystem is OK, i.e. it is very probable that the tool you attempted using to shrink/resize the partition simply wrote the current (wrong) entry in the partition table and failed/crashed/exited without modifying the filesystem :).

But it is well possible that the filesystem suffered from some damage :(.

Until you do not write the "good" partition table and reboot, you can copy files manually (through the TESTDISK interface) "as they are".

Once you reboot there are two possibilities:

  1. the volume is marked for an automatic CHKDSK ("dirty" flag)
  2. the volume is NOT marked for an automatic CHKDSK

In any case, as said, running a CHKDSK is strongly encouraged as first thing.

Now, when you run CHKDSK without knowing if there is a damage in the filesytem (or the extents of this damage) you cannot know in advance what will happen.

If there are no damages, then there won't be any problem.

If the damage are small/trifling or however "repairable", again there won't be any problem.

If the damage is serious, there is a concrete chance that CHKDSK won't be able to fully repair the volume and the process of running CHKDSK may even make a given file not recoverable anymore.

And we are back to the general advice of always imaging a disk that presented issues, so that you can "go back" and try something else if what you are doing failed.

As said, I do understand why you are not able to do that, but from there to make me say "Ah, well then it's OK, no need to image the disk, just write the partition table and everything will be OK" there is quite a largish leap.

Most probably there are no damages to the filesystem or they are fixable by CHKDSK (and there won't be any issues even when attempting booting form that volume), but you won't :no: manage to make me tell you "Go ahead, no prob whatsoever", as YMMGV. :unsure:

jaclaz

Link to comment
Share on other sites

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?

Yes and no. :w00t:

Meaning that with 99% of probabilities, since you can see your files in the "simulated" partition scheme that TESTDISK found, it should mean that the filesystem is OK, i.e. it is very probable that the tool you attempted using to shrink/resize the partition simply wrote the current (wrong) entry in the partition table and failed/crashed/exited without modifying the filesystem :).

But it is well possible that the filesystem suffered from some damage :(.

Until you do not write the "good" partition table and reboot, you can copy files manually (through the TESTDISK interface) "as they are".

Once you reboot there are two possibilities:

  1. the volume is marked for an automatic CHKDSK ("dirty" flag)
  2. the volume is NOT marked for an automatic CHKDSK

In any case, as said, running a CHKDSK is strongly encouraged as first thing.

Now, when you run CHKDSK without knowing if there is a damage in the filesytem (or the extents of this damage) you cannot know in advance what will happen.

If there are no damages, then there won't be any problem.

If the damage are small/trifling or however "repairable", again there won't be any problem.

If the damage is serious, there is a concrete chance that CHKDSK won't be able to fully repair the volume and the process of running CHKDSK may even make a given file not recoverable anymore.

And we are back to the general advice of always imaging a disk that presented issues, so that you can "go back" and try something else if what you are doing failed.

As said, I do understand why you are not able to do that, but from there to make me say "Ah, well then it's OK, no need to image the disk, just write the partition table and everything will be OK" there is quite a largish leap.

Most probably there are no damages to the filesystem or they are fixable by CHKDSK (and there won't be any issues even when attempting booting form that volume), but you won't :no: manage to make me tell you "Go ahead, no prob whatsoever", as YMMGV. :unsure:

jaclaz

So I restored the partition table and from my other OS, the drive was accessible. CHKDSK never showed up. I tried booting the OS but it restarted as soon as I selected it so I ran startup repair off a DVD which said it corrected some problems. So after that , the second OS booted just fine like before but the original OS went past the starting windows screen and then said that 'pwnative' and 'autochk' were missing and that they were skipped. Then it went to a bluescreen saying that the Session Manager Initialization system process terminated unexpectedly.

Now for some weird reason, the second OS won't start correctly unless it is in safe mode. Never mind, it just derped during resuming from sleep.

Edit 2: On the original system, I selected Last known boot configuration and it worked, IT BOOTS!!!!!! :w00t::w00t:

Edit 3: It seems CHKDSK does not want to co-operate as it says the path is invalid whenever I try to run it.

Edited by Torchizard
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...