Hi! I am trying to get a 4.5GB image on a new microSD card which only appears as having 31.9 GB capacity and cannot find a way to get around this “too small” error saying the image recommends a 32 GB drive and mine is only 31.9 GB. Since the image is so much smaller this shouldn’t matter.
Thank you!
Hi @asod614, welcome to balena forums!
Can you please provide more information about your setup?
We usually ask for the following as they help us troubleshoot the issue:
- Etcher version:
- Operating system and architecture:
- Image flashed:
- Do you see any meaningful error information in the DevTools?
(You can open DevTools by pressing Ctrl+Shift+I (Ctrl+Alt+I for Etcher before v1.3.x), or Cmd+Opt+I if you’re on macOS.)
I am running balenaEtcher 1.5.109 on the most updated version of Windows 10 x64, flashing a .dmg image, given to me by a professor, for a Raspberry Pi. I have flashed the same image successfully onto a different brand of microSD which appears as 32 GB using balenaEtcher so I know it has all worked before. There is no meaningful error information in the DevTools since I am unable to even select the “too small” drive. Thanks!
Hi @asod614, you mention you’ve got an image for a Raspberry Pi, given to you by your professor.
Could you please let us know which image that is? Is it to be found somewhere publicly? It may help us to reproduce this issue.
Hello asod614, it looks like the file is a compressed Apple Disk Image file, is that the case? Although it is only 4.5 Gb in size, when expanded by Etcher (or any imager/unzipper) it looks like it needs at least 32GB. Many SD cards do report less than the full 32GB available, so that is likely why you are getting the “too small” error. Do you have a larger card you can try?
Hi alanb128, you’re absolutely right that it is compressed and would be much larger, although I have successfully etched onto a “32 GB” drive with plenty of empty space, this “31.9 GB” drive will not even allow me to start to etch so it isn’t actually too small, it is just an erroneous error that I am trying to get around (my professor told me to post here since he didn’t manually set this minimum drive size). Thanks!
Hi, most of the times, 32Gb - or whichever a target size may be - is just a rounded-up measurement: the actual size is often less and it can be verified by checking the size of the source vs the size of the target (in bytes). That would be a fairly reliable source of truth and if the size in bytes of the decompressed image is bigger than that of the target, there’s not much we can do. Maybe the image can be optimized to require less space? e.g. by removing empty sectors if they’re not needed
I have a similar issue after upgrading macOS 11.0.1. Images that I could previously flash to a 32gb sd are now identified to be too big for the same sd. Identical files and sd worked prior to upgrade.
Hello Patrick
Which image are you using ?
Which Etcher version worked ?
Thanks for the reply.
The image is a backup of a RPI Buster sd with basic configurations for my network etc.
my Etcher version is 1.5.112.
I have flashed it with both Etcher and another program (applepibaker) in the past with success. Now neither will work despite the same image file and microSD card
@pjphel can you tell us image size and format? Also which etcher version you used successfully in the past?
Sorry for my slow response. the .img is 31.06GB, Etcher says the sd card is 31GB. I am not entirely sure what the version that last worked, I just updated when I had the error. I suspect it would have been about 1.5.2 or so. thank you
Hi
- Can you try with the latest version of Etcher? If there’s indeed a bug, it would be easier to debug on the latest version.
- Can you also share the exact size that you see of your SD card, also from the Disk Utility in your macOS? Please share a screenshot if possible.
- Also, from the Terminal app of your MacOS if you can run
ls -lah name-of-your.iso, and share the output, we can compare sizes.
sorry, I guess I was not clear. I have tried on the latest version as well. The last version that I suspect worked was around 1.5.2.
Hi there, can you please try writing a smaller image or using a larger (64GB) SD card.
May I suggest PiShrink? I’ve reported a similar incident myself and I’ve been able to resolve it.
Not all SD cards are exactly the same size. They can differ by 100’s of MB. However, if wanting to flash SD card images of Raspberry Pi filesystems, then PiShrink can shrink the card’s image to the actual size of used space. This new, shrunken image can fit on much smaller cards. Once you flash a new SD card and boot from it, you can expand the filesystem to use the entire size of the flashed SD card.
So, for example, if your original SD card was 32GB and the new card is 31.9GB the shrunken image will fit on the 31.9GB card and when you re-size the filesystem it then expands to 31.9GB.
Has anyone found a solution? My raspberry pi source image is 32GB and I have a dozen SD cards, all of which report 31.9GB, and so can’t be targets of a clone. I have had other SD Cards cloned fine in the past, but every new batch I buy says 31.9GB so I can’t really use balena anymore. Any ideas?
BTW, PiShrink simply fails;
sh-3.2# pishrink “…/enclayvegroup/development/disk.img” new.img
Copying …/enclayvegroup/development/disk.img to new.img…
tune2fs: No such file or directory while trying to open /dev/disk5s5
/dev/disk5s7
Couldn’t find valid filesystem superblock.
e2fsck 1.44.0 (7-Mar-2018)
e2fsck: No such file or directory while trying to open /dev/disk5s5
/dev/disk5s7
Possibly non-existent device?
resize2fs 1.44.0 (7-Mar-2018)
open: No such file or directory while opening /dev/disk5s5
/dev/disk5s7
/usr/local/bin/pishrink: line 51: + 200 * 1048576 / : syntax error: operand expected (error token is " ")
resize2fs 1.44.0 (7-Mar-2018)
open: No such file or directory while opening /dev/disk5s5
/dev/disk5s7
ERROR: resize2fs failed…
hdiutil: detach: only a single device name can be specified
Usage: hdiutil detach [options]
hdiutil detach -help