Hi, prk0ghy via GNU coreutils General Discussion <[email protected]> writes:
> thank you for the great work on coreutils, i use them so often and > would not know what to do without them. I have an issue with dd that I > am not able to solve myself, that is why I am seeking for help here. > I am trying to copy parts of a disk image to another file. I do this > because the original disk image is 500GB in size but only ~25GB are > actually used by partitions. My Idea was to copy only the first part > of the image. fdisks displays the partitions like this: > > ``` > fdisk -l ./source.imgDisk ./source.img: 465.76 GiB, 500107862016 bytes, > 976773168 sectors > 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: gpt > Disk identifier: AAAAA-AAAAA-AAAAA-AAAAA-AAAAA > > Device Start End Sectors Size Type > ./source.img1 2048 616447 614400 300M Windows recovery environment > ./source.img2 616448 821247 204800 100M EFI System > ./source.img3 821248 1083391 262144 128M Microsoft reserved > ./source.img4 1083392 52891647 51808256 24.7G Microsoft basic data > ``` > > I tried it like this: > > > ``` > sudo dd status=progress count=52891647 if=/source.img of=/target.img > ``` Are you unable, e.g., for lack of space, to copy the whole drive? GPT disklabels have a primary GPT header at the second logical block address (LBA 1) followed by partition entries from LBA 2 to LBA 33. However, there is also a second GPT header at the last LBA (LBA -1) with partition entries from LBA -2 to LBA -33. Wikipedia has a helpful diagram to better understand this [1]. The UEFI spec has a similar diagram but that is a 2300 page PDF. :) Therefore, your 'dd' command does not copy the second GPT header at the end of the disk. Unfortunately, I do not use fdisk enough to know how it behaves without the second GPT header. But you certainly don't want to get rid of it. > After the operation is finished I get: > > ``` > ❯ fdisk -l ./taget.imgGPT PMBR size mismatch (976773167 != 52891646) will be > corrected by write. > Disk ./taget.img: 25.22 GiB, 27080523264 bytes, 52891647 sectors > 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: 0x4afd3a95 > > Device Boot Start End > Sectors Size Id Type > ./taget.img1 1 52891646 52891646 25.2G ee GPT > ``` The warning makes sense. The PMBR (LBA 0) has a dummy partition encompassing the entire drive. In this case, the drive has been truncated so it's size is incorrect. > I have no Idea what is happening. I tried iflag=sync conv=sync but the > result is the same. Is there something I am missing? I would just copy your whole drive if possible since it is easier. Otherwise, you can probably ensure that you 33 free LBAs after the last partition, write the secondary GPT header, and rewrite your PMBR with the correct size. Collin [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg
