0

I have a 64GB SD card with Linux (Debian) installed on it. I want to move it to a smaller SD Card (16 GB).

I used resize2fs and cfdisk to resize the filesystem and partitions, so that now, they look like this:

Disk /dev/rdisk4: 122519552 sectors, 58.4 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): C133B5DA-A507-4080-8DBC-9FAD0E960A17
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 122519518
Partitions will be aligned on 2048-sector boundaries
Total free space is 93159357 sectors (44.4 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  
   2         1050624         7342079   3.0 GiB     8200  
   3         7342080        15730687   4.0 GiB     8300  
   4        15730688        29362175   6.5 GiB     8300

Now, I want to take an image of it with dd.

According to this: https://en.wikipedia.org/wiki/GUID_Partition_Table The GPT backup header is the last 33 sectors. The last sector in use by my last partition is 29362175. As far as I can tell, sectors start at 0, so that's a total of 29362176 sectors, plus the 33 sectors for the GPT backup headers.

In the end, I would expect a command like this to work:

sudo dd if=/dev/rdisk4 of=disk4_backup.img bs=512 count=29362209

When I run that, the resulting disk4_backup.img is the size I expect (15033451008 bytes), but when I run gdisk on it:

gdisk disk4_backup.img

It tells me that the GPT backup header is corrupted. I'm pretty sure I can just get gdisk to fix it using the primary GPT header, but why can't I back up the backup-header in the first place? Is my math wrong? Are my assumptions about where the GPT backup header lies wrong?

Note: gdisk does NOT complain about my original 64 GB SD card with resized partitions. It's happy with the GPT headers on it.

Improve this question

2 Answers 2

Reset to default
1

First off, I believe the GPT backup header is at the end of the disk, so that won't survive trying to make a smaller copy.

Second, you might be better off making matching partitions on the new disk, and copying the partitions, or even making matching partitions and filesystems, and copying the files.

Improve this answer
3
  • Your suggestion makes sense, and should work, but I'm curious if the disk image can be taken like this in one go. Can anyone confirm that the GPT backup header is at the end of the disk, rather than right after the final partition? What if I was to take an image of just the primary GPT header, and the partitions, and let gdisk restore the backup header? What would my dd command look like? dd ... bs=512 count=29362175 ? 29362176?
    – John
    Commented Jan 6, 2021 at 18:21
  • 1
    Since your last used sector is 29362175 your could should be 29362176. I tried a few partitionings, and the backup is definitely at the end. If it was to be after the partitions, it would not be able to be found. Finally, the header appears to include the disk size, so it probably should not copied to a disk of a different size.
    – David G.
    Commented Jan 6, 2021 at 18:34
  • I know at a certain point, it's easier to do what you said and re-create the partition layout and just copy the partitions, but is it possible to maybe update the disk size in the header? Is that something gdisk can do, or perhaps will do automatically when you save? I've been taking disk images using dd for years of MBR disks without issues. It just sucks that GPT, for all its advantages, seems to break that ability.
    – John
    Commented Jan 6, 2021 at 19:00
1

Also according to the wikipedia article, the header includes the location of the backup header, and has a crc, so it is going to be difficult to update it with a new backup address without using gdisk and its r recovery & transformation menu command d Use main GPT header and rebuild backup.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .