You are not logged in.

#1 2012-12-03 17:54:39

amadar
Banned
Registered: 2011-04-15
Posts: 147

[SOLVED] How to clone a GPT drive to a smaller drive?

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 partition

For 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 partition

The 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

#2 2012-12-03 19:18:03

amadar
Banned
Registered: 2011-04-15
Posts: 147

Re: [SOLVED] How to clone a GPT drive to a smaller drive?

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

#3 2012-12-03 20:41:30

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: [SOLVED] How to clone a GPT drive to a smaller drive?

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

Board footer

Powered by FluxBB