The Armbian community has just released the Armbian Imager 2.0 GUI program to easily flash pre-built Armbian-built Ubuntu or Debian images for over 338 boards from 64 SBC vendors. The new version features a slick user interface rewritten from scratch and implements custom user profiles in the settings with username and password, SSH key, Wi-Fi network credentials and country code, timezone, locale, and shell. That means the board is ready to use after flashing. In some ways it’s similar to the Raspberry Pi Imager 2.0, except it covers a much broader ecosystem of single board computers.
To be honest, I had no idea Armbian had an imager so far. The last time I used an Armbian image, I downloaded it directly from their website and used USB Imager or another tool to flash it to a microSD card slot. So it’s a good opportunity to check out the Armbian Imager 2.0 program by downloading and installing it on my laptop.
It’s available for Linux x64/arm64 (Raspberry Pi), Windows x64/arm64, macOS x64 and Arm (Apple M1-M4). I installed it on a laptop running Ubuntu 24.04. Some UI features include dark theme selection and eighteen languages automatically selected from your locale.
The first step is to select the board’s manufacturer, and the platinum vendors, who sponsor the Armbian project, come first. I went with Radxa.
We’re now shown a list of boards from the manufacturer, again listed by level of support with four levels: Platinum, Standard, Community, WIP. I selected the Rock 5B Plus SBC.
In the next step, we can select the operating system, again with a list of images that can be filtered by “Stable”, “Rolling Release”, “Apps”, and “Minimal”. The “Apps” filter will show specific images such as Kali Linux, Home Assistant, OpenMediaVault, etc. I went with the Armbian 26.2.6 GNOME image above.
Up next is storage device selection with the system device hidden by device. My 16GB microSD card was properly detected, and after selecting it, I was presented with a summary, and click on Erase & Flash to start the process.
The utility will download and uncompress the OS image, then write it to the microSD card and verify it.
Sadly, it failed due to a problem with that specific microSD card:
|
1 2 3 4 5 6 7 |
09:31:40 ● flash::linux::writer: Image size: 6140461056 bytes (5.72 GB) 09:31:40 ● flash::linux::writer: Unmounting device partitions... 09:31:46 ● flash::linux::writer: Writing image... 09:35:54 ● flash::linux::writer: Write error at byte 301989888: No space left on device (os error 28) 09:35:54 ● operations: Flash failed: Failed to write at byte 301989888: No space left on device (os error 28) 09:35:54 ● board_queries: Device(s) removed: ["/dev/sda"] 09:35:54 ● operations: Cleaning up failed download |
The uncompressed image size is 5.72 GB, and we’re told there’s no space left on a ~16GB microSD card, so there’s clearly an issue, which the kernel log confirms:
|
1 2 3 4 5 6 7 8 9 10 |
[387400.206648] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s [387400.206657] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] [387400.206661] sd 0:0:0:0: [sda] tag#0 Add. Sense: Medium not present [387400.206663] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 08 1e 00 00 00 f0 00 [387400.206665] I/O error, dev sda, sector 531968 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 2 [387400.206675] Buffer I/O error on dev sda, logical block 66496, lost async page write [387400.206682] Buffer I/O error on dev sda, logical block 66497, lost async page write [387400.206685] Buffer I/O error on dev sda, logical block 66498, lost async page write [387400.206687] Buffer I/O error on dev sda, logical block 66499, lost async page write [387400.206689] Buffer I/O error on dev sda, logical block 66500, lost async page write |
While the program detected the issue in the console, the UI didn’t show any error message, and instead, I got a mostly blank window.
I tried again with an 8GB microSD card, and I got the same result as above in the user interface, but it failed silently in the terminal.
I have enough experience to know that when it’s not the storage device itself that fails, it might be the card reader instead. Since I don’t have a working card reader with me, I installed the Windows version of Armbian Imager 2.0 on the Khadas Mind 2 mini PC and tried again using the card reader in the Mind Graphics 2 dock. I could confirm the 16GB microSD card was indeed dead, but I managed to flash Armbian 26.2 successfully on the 8GB card.
What we haven’t checked out so far is the custom profile option, so let’s do that now by going to the Settings, Profiles section.
Clicking on “+ New profile” will show Network options for Ethernet and Wi-Fi…
… as well as localization, root account, first user options…
… as well as Advanced options, and a preview of the config file stored in /root/.not_logged_in_yet. Clicking Reveal will show the passwords. If you set passwords, you may not want to share the resulting image with third parties since passwords are stored in plain text in the file. I suppose it’s deleted after the first login, but it’s usually possible to mount such an OS image as a loop device to access all files.
We can now click save and create as many profiles as we want. The profile can be selected on the “Confirm Selection” window right before starting the flashing process.
The Armbian Imager program is open-source, and you’ll find the source code on GitHub.
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. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
Looks good.
RPI is no longer an option due to the high cost and low specs.
Having an option to build slim image for an ARM based SBC is a must.
Ironic, recently I used rpi imager and faced a “weird issue”. I was unable to flash any of my couple of microSDs. I even de-dusted my old windows machine. Results the same, failure and no error message or error message that says nothing.
After a moment of thinking (human thinking, not AI) I figured out that my card reader might be the cause of this. Short trip to a dollar store and everything just werks.
I am glad armbian got such convenient tool too. I just hope the error handling will become more verbose in the future
That’s why I prefer boards with eMMC flash, especially when they come with a bootloader that automatically installs operating systems without a Windows utility or a microSD card image.
I’ve wasted so much time because of damaged microSD cards, card readers, and Windows utilities in the past. I have fewer problems with microSD cards now that I know a reliable seller in Thailand, but card readers break just as often.
There are specific logivity microSD cards. Have you used those and they also have had failed?
I don’t have much trouble with microSD cards now that I know where to purchase them. My main issue is card readers now.
The microSD card that failed stayed outdoors in an IP67 security camera that failed due to humidity entering the camera through cracks. It lasted about two years.
> There are specific logivity microSD cards
And there is an insane amount of fake cards which is the real problem that is known for almost decades. Tools are available to deal with this though users are uneducated/ignorant. Check https://fight-flash-fraud.readthedocs.io/en/latest/ for example.
I added a fake SD card detection routine to sbc-bench (in review mode) mostly based on Jean-Luc’s reports of him struggling with fake flash memory in the past.
That’s a brilliant idea!
Nice to see Armbian with our-of-the-box support for so many boards. Not so nice to see it still shackled to systemd, so I guess I will just running Devuan/ARM on my SBCs.
Thank you for reviewing Armbian Imager. We really appreciate your feedback.
We also appreciate you reporting the blank white page issue. We are planning to address and fix it in the next minor release.
Unfortunately, I primarily develop Armbian Imager on macOS, which makes it difficult for us to thoroughly test every supported platform. Reports like yours are extremely valuable and help us improve compatibility across different operating systems.
now that is an exemplary bit of community engagement 🙂
> I primarily develop Armbian Imager on macOS
Over half a decade ago Apple made Hypervisor.framework part of the OS and even the first M1 SoCs had virtualization HW support. As such it’s easy to run Linux or even the junk from Redmond on your Mac. UTM should be OK to test through builds…
I get the point, and yes, tools like UTM make cross-platform testing easier than in the past. But even with UTM, there is still a non-trivial amount of extra effort involved in setting up, maintaining, and validating additional environments properly.
At the moment Armbian Imager is primarily maintained by one developer, so realistically this is the level of support we can provide. I cannot afford to spend additional time re-testing every change across every platform, especially considering the Imager came later and is not the main focus of my work.
I already spend most of my time maintaining SBC support and making sure a certain level of quality is delivered there. That remains the priority, and the Imager is honestly one of the last things I think about.
I am sorry if that is disappointing, but expanding the testing matrix further would currently require more effort than the available resources allow.
I actually used to do more extensive environment replication in the past, but it became frustrating. Reproducing multiple setups often still did not reflect the exact conditions another person was using, so the time investment did not always translate into better outcomes.
That said, reports from users running different systems are extremely valuable because they help identify issues that I simply cannot reproduce locally. Contributions and feedback are what make improving compatibility over time possible.