Jetson Nano img damaged (GPT PMBR size mismatch)

Hello everyone,
I’m having some issues deploying the img of the OS downloading from this link.
I’ve used both win32DiskImager on windows and the dd command on ubuntu 16 to write the .iso on the sd.
Both times when i run the command

sudo fdisk -l

I see 14 partitions and the error GPT PMBR Size Mismatch (26865663!=42270719) will be corrected by w(rite)
Now, We developed a lot of coding in it without noticing this issue: now that we have to clone the whole image on a new SD we are running in a lot of troubles.
The thing is:

  • on Windows (using win32diskimager) I do not see any “Letter” associated with the SD inserted in the slot on the PC. This prevents me from using win32diskimager.

  • on Ubuntu I used the dd command withouth specifing any bs, the cloning was completed, the Operating system is apparently good, I can access the GUI, but some files were missing and (for example) the git folder was corrupted.

How can we solve this? I need a SAFE solution to let me clone the image of the original SD card into others without corrupting it.
thanks in advance

This is incorrect…use “gdisk -l /dev/whichever” instead of “fdisk”. fdisk is for older BIOS style partitions, gdisk understands UEFI.

gdisk supercedes fdisk, although fdisk has many uses. Similarly, partition creation should use gdisk, not fdisk. One GUI app for working with UEFI partitions is gparted.

If you modified any SD card or image with fdisk you should start from scratch with gdisk.

I only used fdisk to see the partitions and I noticed the error. I did not modify the SD with it.
I developed some c++/PHP scripts that I want to deploy to other SD.

Was it fdisk which showed errors? Although fdisk now has some partial awareness of UEFI, a UEFI layout will more or less be an “error” (even though it isn’t really an error, it is just the wrong tool to examine partitions with on UEFI).

Windows will not assign any letter to a filesystem type which it does not understand, and thus there is no letter assigned to any ext4 partition (though I suppose Windows subsystem for Linux could see this, but still this would not likely be assignable as a drive letter). Any time Windows cannot assign a drive letter for Linux content, this is “a good thing”. Any time Windows can assign a drive letter for Linux content, this is “a bad thing” (and likely the filesystem will fail to correctly work with permissions).

Here is an experiment to work with, but it requires not accessing the SD card in any way which might modify it. Trying to mount the card will probably invalidate this. I’m not sure where to get this on Windows, but if you can find a way to view the checksum of a file (it doesn’t matter which kind, e.g., crc32, sha1, sha256, it doesn’t matter…though one type will be faster than another) find the checksum of the binary image used by dd. Then, when the image is copied, copy it back to the host as another file name, and see if the checksum matches. If this were on Linux, and if the SD card as a whole were “/dev/mmcblk0”, and if the checksum is sha1sum, then it would go something like this:

cd /where/ever/the/original/image/is
sha1sum ./my_image.bin
dd if=./my_image.bin of=/dev/mmcblk0 bs=512
dd if=/dev/mmcblk0 of=/copied_back.bin bs=512
sha1sum ./copied_back.bin
# Be sure to erase unused files after this since it is a lot of space.

If the original checksum matches the copied back checksum, then the dd copy operation and the function of the SD card (in combination) are perfect. Any attempt to mount the SD card (including automount, not just manual mount) will possibly alter the image (e.g., through attempts to repair a filesystem or to update mount times in journals), so you have to guarantee no modification prior to viewing the copy back image.

Also note that an SD card as a whole (e.g., “/dev/mmcblk0”) is not usually mountable. Only individual partitions are normally mountable (e.g., “/dev/mmcblk0p”), and even individual partitions cannot be mounted unless they are formatted with a filesystem type the host operating system understands.

I don’t use the Windows subsystem, nor the Windows equivalent to dd, not sure what win32DiskImager is. I can tell you though that if the SD card (or other storage device) is functional I’ve never had dd ever fail to correctly copy an image under Linux (and I’ve used Linux since kernel 1.0.9). Do you have a native Linux host to work with?