Raspberry Pi Imager Makes Flashing OS Images Easier on Windows, macOS and Ubuntu

16 Replies to “Raspberry Pi Imager Makes Flashing OS Images Easier on Windows, macOS and Ubuntu”

1. I’ve never been convinced at all by the benefits of such tools which are only frontends to the basic operation of copying an image to a flash. In the days of CD-based installation, linux users would use “dd” to put their floppy images on floppies and dos/windows users would use “rawrite” and nobody would find this complicated at all. As time passed, some started to add some eye-candy stuff on top of this, hiding all the critically important information and starting to scare the users about what they were about to validate by click on the “start” button. Since this point it seems that many users started to find it complicated to simply dump an image to a device!

   Thus my guess is that the only complicated step people feel is actually *being certain* of what they are doing, and such tools which hide everything probably make them feel even less secure because there’s always this small sing in the end “let’s hope it doesn’t write it to the hard drive”, something that never happened with the regular tools before. You will note that nowhere above on the screenshots there is *any* indication of what device is being destroyed during all the operation. *This* is absolutely scary, and one reason I’d never ever use such a tool. It’s the best way to hear “oh no you ruined all my photos by installing the image on my camera’s SD card which was plugged into the SD card slot”.

   Reply

   1. And when you see empiric stuff like this in the code, you can be sure it will add its dose of entropy in field:

      qDebug() << "sleeping to let Windows discovers there are no partitions"; sleep(2); qDebug() << "done sleeping";

      1 2 3

      qDebug() << "sleeping to let Windows discovers there are no partitions"; sleep(2); qDebug() << "done sleeping";

      Reply

   2. > such tools which are only frontends to the basic operation of copying an image to a flash

      Not talking about the tool above but about balenaEtcher now. Etcher is not just ‘copying an image’ but more importantly by default also verifying that the stuff arrived there correctly. If the image has been provided with a checksum it also verifies download integrity.

      This is the stuff newbies fail with (silent data corruption while downloading and/or flashing) and that’s the reason I only recommend Etcher to anyone. Since it protects you from the most common fails that happen rather often and create insane levels of support efforts later (since an OS image with some occasional bit flips ‘at the right locations’ behaves like weird software malfunctions later).

      I even collected some broken SD cards to demonstrate this. Using dumb tools like dd or the ‘Raspberry Pi Imager’ from above some garbage will be written to the card while Etcher will either stop while flashing or warns when verifying afterwards. dd and other dumb tools will only notify in the first case but are not able to inform the user about silent data corruption since they skip the verify step.

      Reply

      1. Hmmm, ya. Balena Etcher phone home software without (full) opt out option. They even know that they are violating laws like the GDPR (see github and statements from balena) and they just give a sh!t. They take your data and don’t even run, they just take it again and again…

         Reply

         1. Thanks for mentioning this. It pointed me to an interesting alternative: https://github.com/balena-io/etcher/issues/2497#issuecomment-589642836

            Reply

            1. Why wouldn’t someone like to use a 500.000 Kilobytes program to write and verify a image file? I guess this usbimager (https://gitlab.com/bztsrc/usbimager) who claims to do the same in 250 Kilobytes is doing black magic! And how does this even work? Without analytics, ads and other bloatware included? How should this work?

            2. Well, seems usbimager could be little larger because on my Windows it has corrupted GUI. Nothing major but still.

            3. Or just the good old dd if=/dev/sdb bs=1M count=XXX | sha256sum which continues to work and doesn’t come with countless dependencies.

            4. Sure, if you simply ignore the target audience then this is a great optional step nobody takes since it takes time and is optional. 😉

               The target audience (inexperienced SBC users) will find out that there is no dd on Windows, that there are no sdN devices on macOS and most probably they’ve overwritten the wrong disk already in the first step with dd when they wanted to flash an image to an SD card.

               If you look at this from the ‘Linux expert’ perspective this is something entirely different than looking at it from the ‘support novice SBC users’ PoV. There’s a reason resin.io/Balena guys developed Etcher. Since their customers failed to burn SD cards as it happens all the time and everywhere with inexperienced users so they had to develop a tool with mandatory verify to keep support efforts low.

            5. I consider there’s way more risks of wiping the wrong device using a magical tool that decides for you which device to use than by listing all the device names, their characteristics and contents and letting you picking the right one. The problem is that such tools aimed at inexperienced people make a business of keeping them inexperienced. Once you understand how that works you don’t need them anymore or you use them for what they provide (such as easy verification) and you don’t panic the first time you land on a machine where you can’t install or use them.

2. > there does not seem to be a verification step like in balenaEtcher to make sure there aren’t any issues with the MicroSD card or downloaded file

   …or the card reader (writer) or the internal USB cabling if USB3 card readers are used on PC’s USB3 front ports.

   ‘Verify by default’ is what makes balenaEtcher outstanding. Not implementing verify for this target audience is just plain stupid.

   Reply

   1. > Not implementing verify for this target audience is just plain stupid.

      But it turns out it is implemented at the end of the writing process. Just in a way users can skip the verify at any time so guess what those with crappy SD cards where the writing already took ages will do…

      Reply

3. half the battle, was getting it to load !

   Reply

4. I’ve just noticed on RPi Blog they’ve also recently released an SD card speed test program:

   sudo apt update sudo apt install agnostics

   1 2	sudo apt update sudo apt install agnostics

   Source code: https://github.com/raspberrypi-ui/agnostics

   Reply

   1. The tests are modular so they could also throw in another shell script testing for undervoltage easily (problem N°1 of average RPi users not buying their official PSU).

      And I really don’t understand why they implement a check for SD card’s performance in an optional way. In Armbian I added this years ago as mandatory check on 1st boot so at least console users get notified that they’re running off an inferior SD card when they start using the device the first time.

      Reply

5. In no way is it going to be perfection, but has anyone experimented with the Androiid app Pi SD Card imager, by Mike Redrobe. Does it even work?

   Reply

Leave a Reply

Connect with:

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website