The common way to flash OS images to SD cards used to be “dd”. But you could potentially damage your system with a wrong command, it will not do verification after writing the firmware image, and it was not available in Windows, so people had to use Win32DiskImager, and last time I check it did not do verification either.
So Etcher, now called balenaEtcher, became a popular cross-operating systems tool to flash images for Raspberry Pi and other SBCs. It’s easy to use and does verification after flashing. However, the binary is rather large at around 130 MB, and the company started to show sponsors to fund the development of the program, and this was not to the liking of everyone.
During my review of CrowPi2 Raspberry Pi 4 laptop, I encountered an issue with balenaEtcher, which was quickly fixed once I updated the program to the latest version. But commenters pointed out there are now better tools including USBImager, a lightweight cross-platform tool with many of the same features as balenaEtcher.
USBImager is open source (MIT license), takes around 256KB of storage space, support verification, compressed files (gz, bz2, xz, zip), etc….
The table below compares USBImager to balenaEtcher and Win32DIskImager program.
| Description | balenaEtcher | WIN32 Disk Imager | USBImager |
|---|---|---|---|
| Multiplatform | ✔ | ✗ | ✔ |
| Windows | Windows 7 or greater | Windows XP or greater | Windows XP or greater |
| MacOSX | ✔ | ✗ | ✔ (10.14+) |
| Available on Raspberry Pi OS | ✗ | ✗ | ✔ |
| Program size | 130 MB | 11.7 MB (Installer) | 256 KB |
| Dependencies | lots, ~300 Mb | Qt, ~8 Mb | ✗ none |
| Spyware-free and ad-free | ✗ | ✔ | ✔ |
| Native interface | ✗ | ✗ | ✔ |
| Guarantee on data writes | ✗ | ✗ | ✔ |
| Verify data written | ✔ | ✗ | ✔ |
| Compressed images | ✔ | ✗ | ✔ |
| Raw write time | 23:16 | 23:28 | 24:05 |
| Compressed write time | 01:12:51 | ✗ | 30:47 |
You’ll find the source code, and binary image for Windows, Linux, Mac OS, and Raspberry Pi on Gitlab.
It looks great, so I’ve tried the latest version on Ubuntu 20.04:
|
1 2 |
wget https://gitlab.com/bztsrc/usbimager/raw/binaries/usbimager_1.0.4-amd64.deb sudo dpkg -i usbimager_1.0.4-amd64.deb |
The file size is indeed 256KB:
|
1 2 |
ls -lh /usr/bin/usbimager -rwxr-xr-x 1 jaufranc jaufranc 249K Jun 21 20:47 /usr/bin/usbimager |
The total size is a bit bigger since there are other files like the manpage and icons in the Debian package, but the total is still under 300KB.
Let’s start the program. The user interface is really basic and simple with a browse file button, Write and Read buttons, a drop-down list to select a drive, and tick box to enable Verify and/or compress, buffer size selection from 1MB to 512MB, as well as a progress bar.
Let’s enlarge the window a bit, insert a MicroSD card in my PC taken from Raspberry Pi 4, and let’s try the Read function with Compress enabled.
This will create a bz2 compressed file save to the Desktop. I select another directory before clicking on Read, but the program ignored this meaning files will be saved to the Desktop directory by default. Nevermind I can always move the file later on, and the program did the job in about 33 minutes here.
Then I tried to flash an image compression with 7z. This won’t work USBImager only supports .gz, .bz2, .xz, and .zip compressed files. So instead, I just flashed the uncompressed image and it worked nicely.
I have a 2TB USB 3.0 hard drive connected to my laptop, and USBImager correctly filtered it only showing smaller removable drives. You may also want to check out the user manual for more options including the ability to flash an image to a microcontroller over serial and to learn how to build the program from source.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I’m still puzzled how a ‘tool’ including a full Chromium browser even became a thing…
yeah i agree, that etcher thing was a piece of crap, it was also a lot more work then just using dd, but i guese somme people don’t want to use console
Four yours ago Etcher changed everything. Simply by doing “verify after write”. Something those ‘nerds’ believing to be familiar with dd will never understand.
It’s not about some weirdo knowing how to specify CLI parameters for some tool but the average Joe managing to burn an OS image to the SD card that was lying around. And this old crappy SD card failed so the OS image was about to be blamed. With verify this didn’t happen.
Today hopefully a lot of people use A1 rated SD cards. Doesn’t change a bit that verify is important. And that’s the only reason why Etcher was the only tool of choice for roughly 4 years.
>Something those ‘nerds’ believing to be familiar with
>dd will never understand.
As far as I’m concerned if userland has to verify that data was actually written to the card then the whole thing is broken. If you can’t trust dd, the kernel block/mmc layer or the SD card to store data reliably then you probably don’t want to actually use that setup.
Anyhow a script to use dd to write the image, flush the caches and then read it back to validate it is 5 or 6 lines in bash. IMHO the only reason for these writer apps to exist is where you don’t have direct access to write the image (i.e. windows) or do extra work for stuff like making a CD image boot from usb.
Is it really so hard to understand the target audience of Etcher or USBImager? These are not people who are familiar with Unix/Linux but the average Joe having to write an OS image to an SD card.
Back in the day when Balena was called resin.io (some ‘IoT for fleet owners’ stuff) majority of their support efforts dealt with people failing to burn OS images to SD cards. That’s the only reason why Etcher has been started in the first place. To implement verify after write since this is where things go wrong.
And it has never been about dd but about WinDiskImager32 since this was the tool 99% of the average Joes were using 5 years ago until Etcher arrived / became popular.
It apparently IS hard…this person keeps going on so…being clueless.
To be sure, if you’re not using Linux for this sort of stuff, I honestly think you need your head examined- but it’s not my call, or oftentimes theirs.
A good tool that consistently flashes things, warns you when you may be overwriting a drive you didn’t want to, etc. is welcome. Now, the thing here is that Etcher is written in JS inside the Electron framework. That’s neither simple, nor is it lightweight. This one is as well. As for doing it all in scripting? Yeah, but only if you can do Linux for all of the steps. (Something about not being a choice comes to mind…)
It’s immature to go on so about it, folks.
Verify after write exists for real reasons: https://www.hardkernel.com/blog-2/improved-win32diskimager/
The average Joe having to flash an OS image to SD card has no idea about broken/counterfeit cards, data corrupting USB3 front ports, the need to flush cashes and so on.
Something caused people to want to use Javascipt for stuff other than making client-side dynamic web content. They call their headless Chromium thing “Electron”, and it’s the hammer they use to pound the square peg that is Javascript into the round hole that is application programming.
There’s also the Raspberry Pi Imager, released in March. Works great as far as I can tell (only used it for 1-2 images so far).
other bloated electron madness? 🙁
No, Qt QML instead.
Is Qt bloat? Perhaps.
But your average Linux distribution will already have the libraries installed, so it is at least bloat already on your system…
The Imager Ubuntu package is 350 kb.
For Windows, use Rufus. It is well engineered.
I kind of doubt the 256 KB program has all the same functionality. Seriously, 130+300MB is like 16000 times more code.
As noted in the article, it is missing the “spyware” and “adware” functionality that Etcher has. However, since USBImager is open source, you can add them if you want.
> Seriously, 130+300MB is like 16000 times more code.
That should tell you a lot about the code quality in the large one… There used to be full-featured UNIX systems running in less than 256kB as well as graphics games. People just can’t code anymore without copy-pasting pages of crap from stack-overflow to work around a missing argument in a function, and importing Gigs of packages to do the glue. But something as trivial as copying a disk to a file and conversely doesn’t need more than a few hundreds bytes, the rest is only eye candiness.
>> Seriously, 130+300MB is like 16000 times more code.
>
> That should tell you a lot about the code quality in the large one…
Not really. The many MB are not the result of bloated code but of choosing the Electron ‘platform’ resulting in giant binaries since including a browser and tons of crap:
And of course Etcher is doing a bit more than USBImager since when using the ‘catalog mode’ it also handles downloads and download verification of OS images to be burnt. Corrupted downloads are the other source of struggle for newbies but way less common than ‘burning went wrong’. That’s why a mandatory verify after writing is that important. Unfortunately USBImager makes it too easy to uncheck the ‘Verify’ checkbox.
> The many MB are not the result of bloated code but of choosing the Electron ‘platform’ resulting in giant binaries since including a browser and tons of crap
I’m sorry Thomas, but that’s exactly what I call bloated code. Not writing code and instead relying on someone else’s which vaguely matches your needs, and as a side effect, inherit all the bugs, crap and vulnerabilities that come with it is a bloated code practice.
At least in MS-DOS, a floppy disk clone utility needed to control low level hardware interrupts, hardware and operating level buffering, along with asynchronous updates to the user interface. The user interface routines possibly came with their own VGA drivers. A good clone utility might have looked like hard real-time operating system. Some commentators give the impression that nowadays this is quite trivial.
You didn’t need all that for a basic disk copy, which could rely on standard BIOS routines from int13h (disk) and int10h (screen), and be feature-complete in a few hundred bytes. Direct access to the floppy controller, interrupt and DMA were needed only to copy non-standard floppies. But even then, this proved that all of that doesn’t require that much code, even when totally implemented top-down from the UI to hardware chip management. There is absolutely no valid justification for the crap that comes above a few hundred kB.
> I kind of doubt the 256 KB program has all the same functionality
True. Actually usbimager does more. It does also work inverted and you can write your USB/flashcard to a (compressed) image file with it.
Just wondering what “Guarantee on data writes” means here?
Footnote 3 here: https://gitlab.com/bztsrc/usbimager#comparition
what about Passmark ImageUSB
4.4mb, nice GUI, free for personal use
can write many flashes at once
as for Linux: gnome-disks can work (read, write) with full disk image or just selected partition
gnome-disks is nice and all, but it cannot verify the image.
Another cross-platform alternative is Rosa ImageWriter, but it doesn’t support on-the-fly decompression.
http://wiki.rosalab.ru/en/index.php/ROSA_ImageWriter
Actually, etcher support RPiOS now, thanks to Pi-apps