You are not logged in.
Pages: 1
Topic closed
I have a new 750GB GPT-formatted drive with Windows 8 on it, and I'd like to clone it to a smaller 160GB drive. The total data on the Win 8 drive is smaller than the size of the small 160GB drive.
I tried using gparted to shrink and move the second-to-last huge main data partition all the way to the left so as to position it as close to the start sector as possible. Then I moved the last small partition as close to start (left, I suppose it'd be right if we were in Afghanistan) as well. The goal here was obviously to make the last sector of the last partition to be at a spot that fits within the smaller drive.
After the resizing and moving, I used dd to copy the big drive to the smaller drive, then figured when dd hit the end of the smaller drive it would stop. The exact command I used was:
# dd if=/dev/sdb of=/dev/sdc bs=8M conv=notrunc,noerror
After dd finished, I tried looking at the drive, but Gparted throws an error message. The window's title is "Libparted Bug Found!" and the message is "Invalid argument during seek for read on /dev/sdc". After pressing Ignore, a second window with the same title pops up with the message "The backup GPT table is corrupt, but the primary appears OK, so that will be used."
After moving past both message dialogs, I proceeded to look at my drive /dev/sdc. Gparted shows a single "unallocated" entry 149.05GiB in size. I was expecting to see 5 or 6 partitions!
Here's what gdisk shows for the smaller target drive:
┌─[09:55:37/starlancer/amadar/~]
└─╼ sudo gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.8.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!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdc: 312581808 sectors, 149.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9245330-EF43-4FF2-938D-AA320C555F34
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1465149134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1282979501 sectors (611.8 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 534527 260.0 MiB FFFF EFI system partition
2 534528 3553279 1.4 GiB 2700 Basic data partition
3 3553280 4085759 260.0 MiB EF00 EFI system partition
4 4085760 4347903 128.0 MiB 0C01 Microsoft reserved part
5 4347904 106747903 48.8 GiB 0700 Basic data partition
6 106747904 182171647 36.0 GiB 2700 Basic data partitionFor comparison, here's what gdisk shows for the larger source drive:
┌─[09:56:16/starlancer/amadar/~]
└─╼ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 1465149168 sectors, 698.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9245330-EF43-4FF2-938D-AA320C555F34
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1465149134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1282979501 sectors (611.8 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 534527 260.0 MiB FFFF EFI system partition
2 534528 3553279 1.4 GiB 2700 Basic data partition
3 3553280 4085759 260.0 MiB EF00 EFI system partition
4 4085760 4347903 128.0 MiB 0C01 Microsoft reserved part
5 4347904 106747903 48.8 GiB 0700 Basic data partition
6 106747904 182171647 36.0 GiB 2700 Basic data partitionThe start sectors, end sectors, and sizes for each partition match perfectly, so the clone didn't go too bad, and the data is probably intact.
Can I fix these problems? Also, would you recommend a better technique for cloning the larger GPT drive to the smaller drive in the first place?
Last edited by amadar (2012-12-03 19:11:17)
Offline
I managed to fix it by going into gdisk's expert mode then running the 'e' option to move the backup GPT table to the end of the drive (a small, but necessary requirement for the GPT drive to work properly). Here's what it looks like at the command line:
┌─[11:07:09/starlancer/amadar/~]
└─╼ sudo gdisk /dev/sdb
[sudo] password for root: xxxxxxxxxxxx
GPT fdisk (gdisk) version 0.8.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!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
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 312581808 sectors, needs to be 1465149168 sectors.)
The 'e' option on the experts' menu may fix this problem.
Identified 3 problems!
Command (? for help): x
Expert command (? for help): e
Relocating backup data structures to the end of the disk
Expert command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.In the above example, the 'x' command puts you in expert mode, then the 'e' command relocates the backup data structures to the end of the disk, and finally the 'w' command writes all changes and exits. Using the 'w' command is what gdisk means when it says "This program will automatically create a new backup partition table when you save your partitions" (the caution statement regarding the CRC for the backup partition table being invalid).
Last edited by amadar (2012-12-03 19:20:04)
Offline
Your solution is the correct one, but I just want to point out that you've now got two physical disks with duplicated GUIDs. This isn't a problem if you intend to completely wipe the first disk, or at least use it in a different computer; but you should not use those two disks in the same computer. A globally unique identifier (GUID) should be just that -- unique. If two disks or two partitions share the same GUID value, then problems can ensue. (GUIDs used as partition type codes are an exception to this rule, though.) AFAIK, Linux doesn't currently care about this, but it might in the future, and I can make no promises about how Windows or an EFI implementation might react to non-unique GUIDs.
If you want to use both of these disks in the same computer, you can use the 'g' and 'c' options on gdisk's experts' menu to change one disk's GUID and the partition GUIDs on one disk, respectively. (You'd need to use 'c' once for each partition.) Alternatively, you can use sgdisk's -G/--randomize-guids option to do it all at once.
Offline
I managed to fix it by going into gdisk's expert mode then running the 'e' option to move the backup GPT table to the end of the drive (a small, but necessary requirement for the GPT drive to work properly). Here's what it looks like at the command line:
Thanks so much for this. I had no idea how to solve this and it was ruining my day.
Offline
Tinchote, this thread is eleven years old and marked solved. Please do not necrobump.
Closing.
Offline
Pages: 1
Topic closed