Hi i tried using balena etcher to flash an andriod OS to a SD card and on the video i watched it flashed instead of decompressed. also after it fails, i have to reassign a letter path/ format the card to see it again, in the video it shows a partition of the operating system so i dont believe its working after the error screen.
Hi, if you could send us the link of the video that you watched that be helpful in understanding what exactly were you trying to do. Also, when it failed what error did you see from Etcher? Thanks!
Hello, I am having the same issue. I believe they are following how to flash android to a microSD for nintendo switch. Probably one like this: https://www.youtube.com/watch?v=HsJsSJ8CcRE
When we are trying to flash the SD cards, it only “decompresses”, it never “flashes” the card. This leads to an invalid flash and the SD card not showing in the file explorer. Please help us fix this issue! It’s very frustrating!
Same Issue here. Image Link. SD card used: Gigastone UHS-1 64Gb Micro SDXC. Tried it with Rufus and it flashed fine. Before trying Rufus, I also tried the 16Gb image from the same place and it gave the “insufficient space, please try a different SD card” error also. (Not exact words, but close enough for you to know the message.)
Edit: Etcher version is 1.5.99 (I would assume that is the version number in Settings)
Edit 2: Checked your Git Releases and used the x64 1.5.30 portable version and it flashed just fine. I know that is a large gap of versions, but it does show that some commit between 1.5.31 to 1.5.99 broke this type of image. One other main difference is 1.5.99 doesn’t have a regular x64 version. 1.5.30 I used specified x64 in the exe file name if that makes a difference. 4Gb limit and all with 32bit.
as nedloH has stated it is this https://www.youtube.com/watch?v=HsJsSJ8CcRE is the vid, thanks for help!
Kiro, nedloH, can you try this older version for Sanity check so they know it is something in a recent update that broke?
that worked perfectly, thank you
Worked for me as well, thanks!
Hello @Uzephi @Kiro @nedloH
Since v1.5.83, Etcher will try to decompress images before flashing (because it can go faster and skip unused space of ext4 partitions when random reads are possible).
It will only decompress first if the decompressed image size is smaller than 5GiB and half the available disk space on your computer.
You can’t be sure of the uncompressed size of a gzip file as the size field is stored on 4 bytes: this only works up to 4GiB ( check https://www.abeel.be/content/determine-uncompressed-size-gzip-file for details ).
In order to work around this, Etcher will try to get the size of the image from the partition table at the beginning of the image.
Unfortunately, due to a bug in the partition table reading, these switchroot images were estimated to be around 2GiB (which was wrong) so Etcher tried to decompress them first, filling the temporary files folder and eventually failing (if not enough space was available).
The partition table reading has been fixed in v1.5.100 and Etcher will no longer try to decompress these images first.
TLDR: this should be fixed in v1.5.100
One other main difference is 1.5.99 doesn’t have a regular x64 version. 1.5.30 I used specified x64 in the exe file name if that makes a difference.
Windows installers have both 32 and 64bits versions included since v1.5.40, that is why you no longer have
x64 in the name.