Win32diskImager "Not enough space on disk Size: 62652416 sectors. Available: 62333952"

Question

I've been careful to buy the same Samsung 32GB SD cards for all my Rpi3 systems to avoid the dreaded Win32diskImager size error.

All of the Rpi images are stored safely in the NAS as .img files.

When it is time for a new one, I go back to the Orders button in Azon and find the most recent one where it says "You have bought this previously - View Order" - and I buy it again.

They visually look the same, with identical markings:

So now as I am trying to write that image (to any of several of the same-looking cards), they all are showing the exact same error - same numbers.

Here is a bug report ticket where this is discussed. In this bug report both the source card and the target card are identical yet it produces this same result:

Win32DiskImager Creates an .IMG file that is too big to restore to identical media

Excerpt:

Lots of verbage in the comments. Using a 32 Gb card to create an image I get an image that will not load onto an identical 32 Gb card formatted with SDFormatter as directed on several websites. THe message says the image is too large to fit on the target SD card but that there does not appear to be aby data ad I get and option to go ahead anyway, I do nd the SD will not boot in my RPI. Why is this still a problem and what do I do to ise it? HO THE F$W% are you guys universally recommended to clone SD cards for RPI if the program doesn't work?

These guys even tried to restore back to the original card and had the same error - they were quite frustrated.

---

Upon further investigation I have discovered that only this (first) particular image is of a different size:

The one at the top is the one I am trying to restore.

It seems pretty obvious that in the beginning, before I knew to match the images to the cards, that I allowed NOOBS to expand to a larger card.

If that SD card is still in inventory it must have gotten flashed with one of the other images. Or it may be a round-file item - some of my systems are thermally stressed so it happens now and then.

Storage of the .img files is definitely worth the effort. Especially since the NAS can do compression on the image files while they are in warm storage. 7z and ZIP are about the same: Storage requirement is roughly 15% of original size.

Now, I never use NOOBS. I simply clone one of the systems which is most similar to what is needed in the new one, then shut down the original long enough to log into the clone and change the hostname and static IP.

With identical cards the .img included partition sizing was not an issue.

Thought I had all the bases covered.

Until now.

QUESTION: Is there a way to do this image restore?

Answer 1

The SD Cards are NOT exactly the same - they obviously differ in size, and this is normal.

The imaging programs copy BLOCKS from one device to another, as do dd. Win32diskImager is probably not the best, it had a number of issues with Foundation images, and Etcher is recommended.

I use dd to backup my cards, they can be restored to the SAME card, and if you are lucky can make a copy, but this is NOT a reliable duplication method.

See Can a Raspberry Pi be used to create a backup of itself? which has a backup strategy, and lots good discussion (unfortunately a few uninformed posts).

Raspbian has an in-built SD Copy utility which can copy to smaller cards (which can be quite slow).

It is simple enough to create empty space at the end of the card to allow duplication, and many people have discussed this.

Your posted solution may or may not have accurately duplicated your card image. As no errors are reported it might be OK, but I would check the number of blocks on each.

PS your "wipe the partition table and boot sector" will do no harm, it will just use some of the SD Card write capacity and move a number of 4M blocks to other parts of the card, but they will still be there until re-used - this is just the way flash storage works, and is part of the wear levelling process.

To answer your other questions; it is possible to mount the image on any Linux system (including the Pi) and use normal imaging programs to resize partitions. This can be done from the command line or using GParted. (Your image looks like it is NOOBS, and is wasting 1.2GB of your card.)

Answer 2

My answer: Do it the Ubuntu Way. System is a Ubuntu 16.04 LTS on a HP Notebook 15.

I shut down the RPi3 and pulled out the SD card.

Plugged it into the SD card reader with an adapter
It came up in nautilus File Manager as two volumes: boot and root.

Eject both in nautilus.

Then I plugged in the target SD card into a USB adapter
It is blank - brand new.

---

sudo fdisk -l

showed

/dev/sda
    /dev/sda1        145.6G  Linux
    /dev/sda2        3.5G    Extended
    /dev/sda5        3.5G    Linux swap
/dev/mmcblk0
    /dev/mmcblk0p1    1.2G    W95 FAT16 (LBA)
    /dev/mmcblk0p2    28.6G   Extended
    /dev/mmcblk0p5    32M     Linux
    /dev/mmcblk0p6    66M     W95 FAT32 (LBA)
    /dev/mmcblk0p7    28.5G   Linux
/dev/sdb
    (no partitions)

---

If the target isn't blank the best way to prepare it is to wipe the partition table and boot sector:

sudo dd if=/dev/urandom of=/dev/sdb count=24

---

Issue the dd command:

time sudo dd if=/dev/mmcblk0 of=/dev/sdb bs=64k
486984+0 records in
486984+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 9.3 MB/s

real    57m12.455s
user    0m1.310s
sys     1m21.320s

Took the target SD card back to the original system and booted it right up.

It works fine - and now is the correct size and brand new.

---

NEXT DAY: Used Win32DiskImager to make a new image of that system from the new card which is the same size/architecture as all the others.

So all is well. Thank goodness for having Ubuntu sitting right here ready to step in and do the job.

---

Note: dd can also be used to save it on the primary SSD in the Ubuntu system as a .IMG file for backup.

Now that I have gotten to the bottom of this I'll still continue to use Win32DiskImager and cards of the same size. All saved in the Windows NAS system.

---

Next step: Following up on Milliways' tips in comments regarding manipulation of .IMG files, which are basically virtual disks much like .ISO files.

That can be verified on Ubuntu this way:

fdisk -l name.img

and it will list the partitions.

Mounting them is not difficult.

Mounting Disk Images (ForensicsWIKI.org)

---

Now am on the trail of resizing them in Windows for the wider audience of RPi users.

Answer 3

I met this error in win32diskimager, I also to decrease the image file, but it doesn't work.

I have tried etcher in windows, it also report destination sd card is too small. so I try dd from git bash, it works because dd just copy data, don't care size.

Answer 4

Came across this today - best solution I found for ease was PiShrink - ran it on a 2nd Pi on my existing disk image and it only took about 30s to run!