In the end all went well using the default schema selected by testdisk but I had a backup in my hand.just in case. If it's any comfort I had a 1TB drive go ping and went through similar pangs deciding what to do. In your position I would proceed and repair the table as per the schema you list safe and confident in knowing that I had prepared an image that I can restore to the original disk and try again if it goes wrong. Since the one being used by testdisk finds your files it is the one you should use in recovery.
GPT / MBR are just different formats of partition table. LVM will not be seen at this level but will be picked up at boot when the repaired OS loads the LVM modules and reads the LVM layout from your resurrected system. That said, testdisk should choke if you ask it to write an invalid table. The only issue that gives me any cause for concern is that the start and end addresses are the same and not consecutive. This is good and, again, the fact that testdisk can use the partition table it has created/inferred from the disk to get down to file level is again confidence inspiring. When these are contiguous then the partitions don't have gaps between them and it is likely that they are part of a coherent partition schema. If you look at the guide you should be able to see that the figures you are interested in are the first figures in the start and finish column. Don't forget that testdisk is using the same schema to find your files that it will write to to a repaired partition table. You found the partitions, verified the content by examination, they are what you want to recover. Testdisk should identify the available partition types automatically and the fact that it found an INTEL partition is not a worry. It seems from your post that you have read the TestDisk guide. I ended up copying the drive with dd, reinstalling the OS and recovering the data by mounting the old partitions in this way.īefore you go any further create ( dd) an image of the disk that you can use to restore it if things go badly wrong. I marked with a * at the end of the line the apparently legit partitions. The partitions with files are 1st (EFI), 2nd (/boot), 4th (/home), 7th (/). Here all the partitions found by an in depth search: Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63 I throw in the question regarding the extended partitions because apparently I have no way to set them all to primary (this make me think it's MBR) and I would need an extended one, but I am unable to create it. Third question, given that testdisk can identify some partitions, I could try to restore the partition table using those values, but what about LVM? What about GPT? How can I restore the previous situation, given that these partitions seem to be properly identified? I am not sure if partitions were extended/logical in some way, I don't even know if that makes sense with GPT and it's not limited to MBR. Since I can see the files, I recovered /etc/fstab and /etc/lvm/, which indeed show that the system was configured using LVM. The fourth partition contains home folders and the last one contains the root. The second partition is the boot partition, contains efi, grub2, vmlinuzs etc. The first partition contains EFI stuff, such as drwxr-xr-x 0 0 0 3 19:26 EFI If I look inside these partitions, using the P: list file command, I can see that
33 69 36), how do I interpret these values? Second question is related to the values displayed: there are 3 values in the start column (e.g.
Testdisk none partition full#
When I run a Quick Search (or even a full search), the tool finds some partitions, and among these there are 5 partitions that make sense: FAT32 0 32 33 33 69 36 532480 When starting, the tool finds this partition only: Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63 So, first question: is Intel partition type a MBR? Why does EFI GPT not work even if the disk label is GPT? I tried searching for partitions with both types, but only Intel was successful. I tried running testdisk, which identifies the partition table type to be Intel (and not EFI GPT). fdisk report the disklabel type to be gpt. So, in the disk with the OS, /dev/sdb, 128GB SSD, there is no partition table. The BIOS still detected the disks properly, so I started a LiveDVD to see what's going on. So, somehow the partition table on my disk went bananas: at the next boot the system would not start, I got repeatedly kicked in the BIOS and I had no viable boot options.
0 kommentar(er)
