Igor

I have to be upfront: I'm not a developer. I'm an ops/observability engineer who knows how to use software to get things done. I know a bit of Go — not much — and I have no formal background in software design. What I do know is what I need, and what was missing. So I built it. Take the code with that in mind.
 
The problem
 
I run a Kobol Helios64 as my home NAS — a five-bay ARM board that's been sitting in a sweet spot between "serious hardware" and "abandoned by its software ecosystem." I tried the usual NAS UIs. They were either too heavy, too opinionated about owning the underlying OS, or simply unmaintained. None of them gave me a clean window into my ZFS pools without dragging in a container runtime, a Node.js server, or a Python daemon alongside them.
I wanted something simple: observe and manage my storage from a browser, on a machine that stays close to a vanilla Armbian or FreeBSD install. No agents, no frameworks, no surprises.
 
What I built
 
dumpstore — a lightweight ZFS management UI written in Go. link: https://github.com/langerma/dumpstore
 
It's a single compiled binary with a bunge of html/js/css/ansible playbooks. No database. No Node. No container runtime.
 
Ansible handles writes (dataset creation, snapshots, user/group management, ACLs)
 
Current features:
Pool overview — health, usage, vdev tree, fragmentation Live I/O statistics per pool (SSE-pushed, no polling) S.M.A.R.T. data per disk — temperature, power-on hours, reallocated sectors Dataset browser — collapsible tree, compression, quota, mountpoint Dataset create / edit / delete Snapshot management — list, create (recursive), delete User & group management — create, edit, delete; system users protected ACL management — POSIX and NFSv4, recursive apply supported Prometheus /metrics endpoint (because of course) Runs on Linux (systemd) and FreeBSD (rc.d) Builds with make build && sudo make install — that's it  
What it is not: a full TrueNAS replacement.
 
SMB/NFS share management, a file browser, and ZFS send/receive are on the roadmap — but I'm building deliberately, one thing at a time.
 
Why Armbian specifically
The Helios64 is the reason this exists. If you're running Armbian on a Helios64, an older ARM server, or any ZFS box where you care about what's actually installed — this was built for you.
 
Feedback welcome
Since I'm not a developer by trade, I'm sure there are things I've done in a way that makes experienced Go or software folks cringe.
Issues, PRs, and honest feedback are very welcome.
 
The code is small enough to be auditable — main.go plus a handful of internal packages.
 
Markus Langer
 
 
 

Try to build from this PR:
 
https://github.com/armbian/build/pull/9381
 
- use CURRENT branch
- enable additional DEBUT if it doesn't proceed
- leave u-boot as is or try with most recent

At this point, the most realistic path is to use hardware that is already officially supported. Bringing up new hardware or maintaining outdated vendor kernels requires significant engineering time and resources. Board enablement is not a small task. It involves ongoing maintenance, testing, integration work, and long-term support. This represents real cost for the project while public project funding is not even on the level to cover response of such ideas. If you are expecting someone will just emerge and spent months of his private time in exchange for: constant insults, hate and complete absence of financial coverage for the time spent (things are never in perfect state to satisfy over-spoiled customers of someone else) ... adjust expectations.
 
We encourage users to choose hardware wisely - that already has active support and to contribute back to the project when possible. That is the only way we can avoid overextending limited resources, burnouts, collapse.

Vendor kernel will stay for awhile (this year for sure) as mainline is not on this level yet.
 
 
This part might not be part of the release - you can grab it from nightly release - but most likely it won't have any affect to this topic.

It really is as simple as possible on Armbian.
Pretty good documentation too, I posted it before, but here you go again: https://docs.armbian.com/
 
All you have to do is to login as root from an ssh client following standards.
I do not have access to a windows installation where I can confirm if what you say is true, that the ssh client does not let you login with "ssh root@xxx.xxx.xxx.xxx", so maybe you are correct, but it sounds very unlikely to me.
But what I can guarantee is using an ssh client from another unix system will definitely let you connect.
 
So use a mac or a linux computer to access.
Or install wsl on windows and do it from there.
https://learn.microsoft.com/en-us/windows/wsl/install
 
Edit:
I actually forgot, but I had putty installed on my system. I used it to check colors in a script I maintain and it exists in the extras repo on arch.
Downloaded latest minimal image for rpi (so not same hardware as you) and...

 

 

 
No settings changed in putty, just a standard root@192.168.99.60 that I added into the "Host Name (or IP address)" field and clicked "open".
 
Name            : putty
Version         : 0.83-1
 
So I don't know what to tell you...

... problem is elsewhere. This is running:
 
sudo dpkg-reconfigure tzdata  
in CLI (Armbian Noble), choosing region Atlantic, then:
 

One option is to start a crowdfunding campaign. You can review how previous campaigns were structured here: https://forum.armbian.com/crowdfunding/
 
As a rough estimate, bringing a new board or image to a sustainable level typically requires around $5,000 just to cover the initial development effort - when dealing with something simple. Running a campaign also gives a clear picture of how challenging it is to secure funding for this type of work.
 
However, initial development is only part of the cost. To avoid creating another long-term maintenance burden (a “support black hole”), an additional $5,000–$10,000 is usually needed to cover ongoing maintenance, updates, CI resources, testing, and long-term support.
 
It’s also important to emphasize a general principle: you should ideally choose hardware that is already officially supported, rather than expecting support to be built around hardware after purchase. Supporting embedded devices sustainably requires planning, funding, and long-term commitment — it doesn’t happen automatically.
 
In short - it’s possible, but it requires realistic budgeting and shared responsibility.

Auto generated images:
 
https://dl.armbian.com/nightly/orangepirv2/Forky_current_minimal
https://dl.armbian.com/nightly/orangepirv2/Noble_current_xfce
 

Board: MKS-Klipad50
Images:
* Armbian_26.2.1_Mksklipad50_noble_current_6.18.8_minimal.img.xz
* Armbian_26.2.1_Mksklipad50_trixie_current_6.18.8_minimal.img.xz
Passed tests:
* gpg and sha checksum files
* boot from emmc, leds, display, touch, usb, internal wifi
* initial setup, uboot-console, full klipper/klipperscreen install, reboot
Result: All expected images do exist, verify and work properly.

We are opening public testing for upcoming Armbian images. The goal is to verify that the right images are built and that basic functionality works before boards are moved to the main download pages.
You don’t need to be a developer. Simple testing and short reports are enough.
1. Download testing images
Testing images are available here: https://fi.mirror.armbian.de/incoming/igorpecovnik/  Pick the image matching your board and choose desktop if applicable. 

Once image is confirmed working, the board will be:
Moved to the main download pages Added to Armbian Imager 2. Check that expected images exist
Before testing, please verify that:
Your board is listed The expected image variants exist If an image (variant) seems to be missing:
Check the release target definitions:
https://github.com/armbian/armbian.github.io/tree/main/release-targets If the image should exist, check build logs to see if it failed:
https://github.com/armbian/os/actions/runs/21642728389 If you are unsure, report it anyway.
3. Flash and boot
Flash the image using Armbian Imager: https://imager.armbian.com
Boot the board and check whether it reaches:
Login prompt (CLI images) Desktop (Desktop images) If the board does not boot, serial output or photos help.
4. What to test
Please focus on basic functionality:
Boot reliability and reboot Networking (Ethernet, Wi-Fi, Bluetooth) Display and GPU, if applicable Installer and first-boot experience Advanced features can wait. Stability comes first.
5. UEFI ARM64 images
If your board might support UEFI on ARM64, please test those images on them. Working UEFI images allow us to reuse targets and reduce the number of generated images.
Reference:
https://github.com/armbian/armbian.github.io/blob/main/release-targets/reusable.yml
6. Community-supported boards
Some boards are currently released as community-supported: https://github.com/armbian/community/releases 
We want to promote suitable boards to standard support which brings more image variants and much faster download. This requires:
Confirmation that basic functionality works Send a PR to change status from .csc to .conf A community member willing to step up as maintainer If you rely on such a board and want it promoted, this is the time to help.
7. Reporting (here in this topic!)
When reporting test results, please include:
Board model Image name and variant What works and what does not Logs or serial output if available Even short reports like “Board X, image Y, boots and networking works” are useful.
Thanks to everyone helping with testing. Early feedback directly improves the release quality!

We are opening public testing for upcoming Armbian images. The goal is to verify that the right images are built and that basic functionality works before boards are moved to the main download pages.
You don’t need to be a developer. Simple testing and short reports are enough.
1. Download testing images
Testing images are available here: https://fi.mirror.armbian.de/incoming/igorpecovnik/  Pick the image matching your board and choose desktop if applicable. 

Once image is confirmed working, the board will be:
Moved to the main download pages Added to Armbian Imager 2. Check that expected images exist
Before testing, please verify that:
Your board is listed The expected image variants exist If an image (variant) seems to be missing:
Check the release target definitions:
https://github.com/armbian/armbian.github.io/tree/main/release-targets If the image should exist, check build logs to see if it failed:
https://github.com/armbian/os/actions/runs/21642728389 If you are unsure, report it anyway.
3. Flash and boot
Flash the image using Armbian Imager: https://imager.armbian.com
Boot the board and check whether it reaches:
Login prompt (CLI images) Desktop (Desktop images) If the board does not boot, serial output or photos help.
4. What to test
Please focus on basic functionality:
Boot reliability and reboot Networking (Ethernet, Wi-Fi, Bluetooth) Display and GPU, if applicable Installer and first-boot experience Advanced features can wait. Stability comes first.
5. UEFI ARM64 images
If your board might support UEFI on ARM64, please test those images on them. Working UEFI images allow us to reuse targets and reduce the number of generated images.
Reference:
https://github.com/armbian/armbian.github.io/blob/main/release-targets/reusable.yml
6. Community-supported boards
Some boards are currently released as community-supported: https://github.com/armbian/community/releases 
We want to promote suitable boards to standard support which brings more image variants and much faster download. This requires:
Confirmation that basic functionality works Send a PR to change status from .csc to .conf A community member willing to step up as maintainer If you rely on such a board and want it promoted, this is the time to help.
7. Reporting (here in this topic!)
When reporting test results, please include:
Board model Image name and variant What works and what does not Logs or serial output if available Even short reports like “Board X, image Y, boots and networking works” are useful.
Thanks to everyone helping with testing. Early feedback directly improves the release quality!

Inspired by the incredible work @jock and @ilmich have done to make the RK322x platform stable on mainline Linux, I decided to tackle the application side of things. My goal was to turn these "e-waste" TV boxes into fully functional, low-latency Android Auto head units for our cars.
 
This fork of OpenAuto is built as one of my "Is it possible to turn this into that?" projects. It turned out to be one heck of a nightmare to pull off, but at the same time a lot of fun because I can see the potential of these TV Boxes as something you can actually put in your car and turn into a usable head unit!



 

 
System Requirements
Target Device: RK322x TV Box (e.g., MXQ Pro 4K). OS: Armbian Bookworm or Trixie (Kernel 6.1+ recommended). RAM: 1GB recommended. FFMPEG Installed: This build requires a specific build of ffmpeg that can be found here.  
Release: v2.0.0-alpha
This release represents a major architectural overhaul. I have removed heavy dependencies (PulseAudio, QtAudio, GStreamer) in favor of a lean, direct-to-hardware pipeline using RtAudio (ALSA) and FFmpeg v4l2_request.
 
Download:
https://github.com/Harleythetech/openauto-rk3229-armbian/releases
 
Technical Details
Video Engine: Switched from GStreamer to a custom FFmpeg + V4L2-Request backend. Leverages the v4l2drmprime patch set for Zero-Copy rendering. Enables full hardware H.264 decoding on Rockchip stateless decoders. Result: Stable 1080p 60fps stream on a 1GB RAM device. Audio Overhaul: Replaced PulseAudio and QtAudio with RtAudio. This creates a direct, low-latency path to the ALSA hardware driver. Display: Targets linuxfb (Framebuffer) by default instead (eglfs and ffmpeg have issues when you run them together due to DRM master lock)  
Configuration
This release requires a specific ALSA configuration to allow audio mixing (dmix) without PulseAudio. Create/Edit /etc/asound.conf:
 
pcm.!default { type asym playback.pcm "dmix_hdmi" capture.pcm "plug_null" } ctl.!default { type hw card 0 } pcm.plug_null { type plug slave.pcm "null" } pcm.dmix_hdmi { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm { type hw card 0 device 0 } format S16_LE rate 48000 channels 2 period_size 512 buffer_size 4096 } bindings { 0 0 1 1 } }  
Known Issues
Invisible Cursor: The mouse cursor works but is currently invisible when the FFmpeg video backend is active (rendering layer order issue). Backend Fallback: In rare edge cases where DRM initialization fails, the app may incorrectly default to Qt software output. Probably more, i haven't tested it that much  
 
Development Status: Active & Seeking Contributors Currently, I am the sole maintainer focusing on the RK322x platform (specifically the RK3229).
I am actively looking for developers interested in expanding support to other devices (such as RK3328, RK3399, or Allwinner H3/H6). If you have experience with C++, Qt, or V4L2/DRM and want to help turn these TV boxes into capable head units, contributions are highly welcome!
 
Repository: https://github.com/Harleythetech/openauto-rk3229-armbian
 
 
Credits:
@jock and @ilmich for ffmpeg patches and the csc-armbian-for-rk322x-tv-box-boards opencardev for openauto and aasdk

Rpi support for whatever of their devices is mainly on the level of RaspberryPi OS. We use their kernels sources as base, add some additional things and release timing is different - not much difference. If they added new device, it should just work. 
 
If anyone wants to improve support or fix WiFi -> https://github.com/armbian/build/pulls

Thanks Igor.
Just for reference, I also tried Armbian_community_26.2.0-trunk.332_Odroidhc4_forky_current_6.18.7_minimal.img
 apt update
 apt upgrade
 apt install linux-headers-current-meson64
 apt install zfsutils-linux zfs-initramfs zfs-dkms zfs-zed
 
Everything went fine and seams to working OK.
 
Chris

It is a AP-mode problem of the Realtek 8822CE chipset. Replaced the M2 card with Intel AX200 card and since then solid as a rock

I had to rebuild server and this was not fixed yet. Temporally location https://stpete-mirror.armbian.com/users.armbian.com/

Stick to this board: https://www.armbian.com/bananapicm4io/ So far we have a person behind and a tiny budget, so our personal finances are not blown in 100%. Behind Orangepi CM4 we have nothing except random community work and with this it is not possible to plan any actions.

Armbian recently merged and will be releasing (and backporting) a patched devicetree file for the Odroid C4 and HC4 that eliminates the second power-cycle "glitch" during boot.
Hopefully this will fix at least one issue people have been reporting, where some HDDs (or other devices) do not react well to rapid power double-tap during boot.
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch
 
It will also be released (and likely backported) upstream in next Linux kernel release and/or fixes.
 
Also, something else people have been reporting is the HC4 struggling to spin up two large HDDs at the same time.  If you have an HDD with a "Power Up In Standby" (PUIS) setting, such as the Seagate IronWolf, then you can configure all non-system (non-boot) drives in this manner, and then mount and access them sequentially after the system has booted.  Depending on how much power the HDDs use in regular operation, this might work to get both spun up and running.  Theoretically, you could also access just one drive at a time and then place it back in standby before using the other drive. YMMV.

They are not empty. You need to go one level deeper:
https://armbian.nardol.ovh/dl/tinkerboard/archive/
 
BTW, try https://github.com/armbian/imager It will be much easier.

In the past (2019)
there was no chance to use the A64-CPU Jide Remix Mini with armbian, because of a blocked -u-boot

But today I found a site (from February 2025 on github)
https://github.com/r4nd3l/revived_remix_mini_pc?tab=readme-ov-file
which can make the Closed Jide Remix Mini to boot from SDCard with a modified u-boot

There at the github page is a modified u-boot and a modified A64 armbian for the Jide Remix Mini.
Jide did leave us with a closed/blocked device  AT this time the 16GB emmc isnt useable, but using SDCard is a start for upcycling the Jide Remix Mini
 

We are slowly releasing v25.11 images and here I did some mess-up, fixed now. We don't offer Bookworm anymore, so Trixie it is. If you need to Bookworm for some reason, you can build on your own or use the one from archive: http://archive.armbian.com/

Attached torrent will download super fast.
Armbian_25.11.1_Helios64_trixie_current_6.12.58_minimal.img.xz.torrent

We only provide mainline based kernel, where video acceleration might not work. If you have a need for that, than use those hints:
 
add DT here:
https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts
enable vendor kernel 
https://github.com/armbian/build/blob/main/config/boards/odroidm1s.csc#L7
build with ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu" and desktop will work faster, video acceleration will most likely just work OOB.

I guess this should do:

Hello, another Odroid M1S owner and user here. I tried the Ubuntu image because I was curious about video acceleration in particular. So I installed Kodi and played a few videos. There is no acceleration. This means that this image is not usable as a player. However, it will probably be usable as an SMB/NFS server (I'll try using it that way for a while).
A few comments:
- Gnome is relatively slower, but not unusably slow (I personally don't mind, because I don't intend to use the M1S as a desktop)
- Gnome sometimes has problems rendering windows, there are strange stripes, only in certain parts of the windows, and at times it is so annoying that it becomes unusable
- Personally, I would love it if someone experienced could take a working GPU driver and put it into this image. That would solve everything, and we could all use the M1S to our full satisfaction (however, it's probably not that easy, because otherwise the guys at Odroid would have already done it).
- I will add relevant links to a functional accelerated solution that makes the M1S a fully functional driver, but based on the very old and not very usable 5.10 kernel
- https://forum.odroid.com/viewtopic.php?f=217&t=47621 here is a functional Odroid based image solution for media player.
- By the way, I managed to upgrade the image mentioned here to Ubuntu 24.04, using the Kodi build for Odroid M2 ( https://forum.odroid.com/ viewtopic.php?f=235&t=49005 ), but I had to stay on kernel 5.10, and even this version works relatively well as a functional player with accelerated videos (the old kernel is a prerequisite)
 
I hope that I have contributed at least a little to making this Armbian image gradually become the standard for M1S, because this computer deserves it.
 
 

So, here's what I had to do to successfully build the image. First, I corrected my board file in the config/board/orangepizero3.csc directory. The processor value was incorrect, it was 616, so I set it to 618.
Menuconf suggested selecting a board with a 618 chip, but in the board file it was listed as family 616.
Later, I copied my board file to the userpatches directory and added the value CONFIG_DRM_PANEL_MIPI_DBI=m. Then I ran the image build script with the menuconf viewer. I was surprised that the CONFIG_DRM_PANEL_MIPI_DBI parameter already had the value "m"; previously, it was empty.
After all these manipulations, the build went smoothly. Thank you so much for your support.