I have a
.vmdk file which I have to extract data from. I added the
.vmdk file as a secondary hard drive(
/dev/sdb) for a virtual machine, and tried to mount it but it was unsuccessful.
# mount /dev/sdb ./target mount: /home/suhdonghwi/Documents/target: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
fdisk and output was:
# fdisk -l /dev/sdb GPT PMBR size mismatch (524287999 != 260503551) will be corrected by write. Disk /dev/sdb: 124.22 GiB, 133377818624 bytes, 260503552 sectors Disk model: VMware Virtual S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdb1 1 260503551 260503551 124.2G ee GPT
GPT PMBR size mismatch (524287999 != 260503551), I ran
# gdisk /dev/sdb GPT fdisk (gdisk) version 1.0.5 Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Warning! One or more CRCs don't match. You should repair the disk! Main header: OK Backup header: ERROR Main partition table: OK Backup partition table: ERROR
Command (? for help): v Caution: The CRC for the backup partition table is invalid. This table may be corrupt. This program will automatically create a new backup partition table when you save your partitions. Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations. Problem: Disk is too small to hold all the data! (Disk size is 260503552 sectors, needs to be 524288000 sectors.) The 'e' option on the experts' menu may fix this problem. Problem: GPT claims the disk is larger than it is! (Claimed last usable sector is 524287966, but backup header is at 524287999 and disk size is 260503552 sectors. The 'e' option on the experts' menu will probably fix this problem Problem: partition 3 is too big for the disk. Partition(s) in the protective MBR are too big for the disk! Creating a fresh protective or hybrid MBR is recommended. Identified 6 problems!
gdisk suggested me to go expert mode and type
e for repairing the problems. But it was unsuccessful again:
Command (? for help): x Expert command (? for help): e Relocating backup data structures to the end of the disk Expert command (? for help): w Warning! Secondary partition table overlaps the last partition by 263782433 blocks! You will need to delete this partition or resize it in another utility. Problem: partition 3 is too big for the disk. Aborting write operation! Aborting write of new partition table.
Saying that I have to resize partition 3 in another utility. So I tried using
parted to do so, but the following errors came out:
(parted) p Error: Invalid argument during seek for read on /dev/sdb Retry/Ignore/Cancel? I Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. OK/Cancel? O Model: VMware, VMware Virtual S (scsi) Disk /dev/sdb: 133GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags:
I think it has something to do with the incorrect size information. I have
.vmdk files. I also tried recreating
.vmdk descriptor file, but with no luck. I ran out of solutions, what should I do?