Help with HDD. Is it a Partitioning Problem?

[Qqmike]

I realize you are still working on this, researching. The open question is what would happen if you let TestDisk use the INTEL search and restore from that ... or the GPT search, but this is just not clear at all. I suspect that utilities can't see this HDD because of some upfront damage/contamination to some header info (like the GPT partition Header, though nothing is admitting it is a GPT). It's a big crap-shoot. If TestDisk did some partition-restoring, would it also check to make sure everything is "hooked up" correctly (headers and all)? That would be nice if it did, or at least render some message about it. Open questions.

[Qqmike]

I need to put this down for awhile. Two possible tasks remain:
google like the dickens and try to locate more information;
and/or
try to investigate deeper, at the level that starman talks about, to try to track down exactly what is on that disk.

This morning, I wrote this down to organize some thinking -->

So is this a valid decision analysis? ;-) WhoTH knows for sure (except, perhaps, Rod Smith).

1 Your "bad" laptop failed to start.

2 Is the HDD damaged? SMART => it seems to be OK
Caveat: TestDisk did refer to a "bad sector" ... is that a bad hardware sector or a bad code embedded in a protective MBR?

3 Is the laptop damaged? You can boot live CDs and other HDDs in it (correct?) => the "bad" laptop seems to work.

Assuming the HDD and the laptop work hardware-wise (and this may not be true), continue -->


4 GParted, TestDisk and, fdisk see empty, unallocated space; TestDisk does find some partitions though.

5 There are many indicators this was/is/could be a GPT booting by UEFI. Ex.: it was a new Windows 8 machine and should come UEFI+GPT ready; the ee code; the EFI GPT strings; and the presence of GRUB EFI files in your Kubuntu /usr/lib/grub (confusingly, though, you also had a legacy grub-pc in there, suggesting an MBR). BUT the acid test is that gdisk doesn't see it as a GPT; it doesn't see it as a damaged GPT; it doesn't offer any repair options when you run gdisk /dev/sdx; it does not tell you that it sees any backup partition headers or partition table; it doesn't warn that it could be a hybrid MBR (and it doesn't look like one BUT could it have been done by some 3rd party utility--run by Dell or Windows-- in an unexpected way?), see:
http://www.rodsbooks.com/gdisk/hybrid.html


--> I'm confused about HOW this thing boots--by GRUB2-EFI? by Windows bootloader? But you did say that you see a GRUB menu. It is not GRUB Legacy, so it must be GRUB-EFI.


6 Would this then work, and what is the risk? -->

Use TestDisk to recover those partitions it is finding, using MBR -- see if it goes OK.
After doing so, will it boot? Do you have to adjust /etc/fstab? re-install GRUB2? (if so, where?, would Boot Repair help here? would rEFInd get your booted up? would this damage a needed protective MBR?) => issues to prepare BEFORE you did this.

Then use gdisk to convert this MBR to GPT.
Do you have room for the GPT header, partition table, backup header, and backup partition table? It seems so, yes -- see Note below.

http://www.rodsbooks.com/gdisk/mbr2gpt.html

Issue:
In your current protective MBR, I do not see any sign that GRUB is installed there (in the first 446 bytes, where it should be). So, was the laptop booting by UEFI? If so, then where is the ESP--we do not see any EF00, EFI System, Windows System Partition, GParted's boot_esp, etc. -- no sign of any ESP. However, you did find grub efi files in your Kubuntu root file system, /usr/lib/grub.
Can you use a live CD to investigate this--try to locate the ESP, look for a directory /EFI/ubuntu (and grubx64.efi etc.) and /EFI/Windows/ ?


Are we missing something here?
Is the Protective MBR damaged and thus misleading us at every turn?


7 Instead of 6 above, how about letting TestDisk restore the partitions as GPT.

Would it also restore/fix the Protective MBR (if necessary) and the GPT partition header, partition table, and backup header and table? Only the author of TestDisk would know (he has been very helpful responding by email in the past). Or, would it fix it "enough" so gdisk could be used to put things in final order? There is, again, the issue of booting: by UEFI? if so, is there an ESP in place that can be used? this must be confirmed. There may or may not be room to create a new one and install GRUB2-EFI to it. For booting, you could install rEFInd instead of GRUB, though, if you can get booted into an OS to do so.


8 Other options:
Write Rod Smith (and donate maybe $10 or $20 -- I'm going to do it now as I've already bugged him last week about some issue).
Call Dell.
Google until you drop.


9 Comment:
If you had a Windows 8 disk to re-install it, you'd have another option:
wipe the entire disk, re-format as GPT, re-install all OSs in 64-bit UEFI mode.


- - - - -

Note:

It seems you have room for a GPT (header, partition table, backup header, and backup partition table), from your output of various utilities (remember, the WINRETOOLS and the PBR are Windows backup partitions):


k /dev/sda - 500 GB / 465 GiB - CHS 7600 255 63 Partition Start End
Size in sectors > HPFS - NTFS
10 168 31 18 119 37 125440 [WINRETOOLS] Sector 31 =>
there is space available for a protective MBR and a GPT partition table header and partition table


Last sector?
Command (? for help): pDisk /dev/sda: 122096646 sectors, 465.8 GiB Logical sector size: 4096 bytes Disk identifier (GUID):
CC1C1049-6685-49DD-89B2-1E1380A65B27 Partition table holds up to 128 entries

First usable sector is 6, last usable sector is
122096640 Partitions will be aligned on 256-sector
boundaries Total free space is
122096635 sectors (465.8 GiB) TestDisk:

Disk /dev/sda - 500 GB / 465 GiB - CHS 7600 255
63 Partition Start End Size in sectors >P MS Data 171264
296703 125440 [WINRETOOLS] P MS Data 296704 62838783
62542080 [OS] P MS Data 62838784 62953983
115200 P Linux Swap 62953984 65203965
2249982 P MS Data 65203968 72703999
7500032 P MS Data 72704000 118788351
46084352 P MS Data 118788352 118877951
89600 P MS Data 118877952 122096389 3218438 [PBR Image]

gdisk: verify v ==>
No problems found. 122096635 free sectors
(465.8 GiB) available in 1 segments, the
largest of which is 122096635 (465.8 GiB) in size.

=> It looks like there is space at the end of the disk beyond the PBR.
The caution is that you do not want to disturb Windows PBR recovery partition.