bedna

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
 
 
 

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...

I'm back

Asking for help on Radxa discord i got the answer to check for the FPC ("Flexible Printed Circuit") cable pin orientation and run lspci next.

Turns out it was the cable all along, lspci returned:
# lspci 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3576 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)  
 and lsblk shows:
 
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 4.5T 0 disk └─sda1 8:1 0 4.5T 0 part sdb 8:16 0 223.6G 0 disk └─sdb1 8:17 0 223.6G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk1 179:0 0 59.5G 0 disk ├─mmcblk1p1 179:1 0 16M 0 part /config ├─mmcblk1p2 179:2 0 300M 0 part /boot/efi └─mmcblk1p3 179:3 0 59.2G 0 part / zram0 253:0 0 1.9G 0 disk [SWAP] So now it works and i can carry on with making my NAS 😇

Stop providing false information, I disproved your theory earlier, please stop.
 
On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian.
This works, and is the way I have ALWAYS done it on Armbian, for years.
 
Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login
I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234."
 
If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

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!

Maybe this helps? https://forum.armbian.com/topic/29427-shrink-backup-a-tool-for-backing-up-sbcs/

Updated to version 1.4. Please see Shrink-backup github for full information.

Release notes:
Autoexpansion added for rpiOS trixie Fixed detection and autoexpansion for DietPi Version included in logfile "Confirmation window" updates: Moved into a function Inclusion of device paths Countdown timer for `ctrl+c` if `-y` option is selected
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

shrink-backup is a bash script for backing up your SBC into a minimal img file with autoexpansion at boot for supported operating systems
Version 1.4
Info updated: 16 Oct, 2025.
Full information: shrink-backup

I made this script because I wanted a universal method of backing up my SBC:s into img files as fast as possible (with rsync), no matter what os is in use.

shrink-backup is a very fast utility for backing up your SBC:s into minimal bootable img files for easy restore with autoexpansion at boot.

Can backup any device with or without a boot partition as long as the filesystem is ext4, f2fs or btrfs (with subvolumes).

Supports backing up root & boot (if existing) partitions. Data from other partitions will be written to root if not excluded.
For btrfs, all existing top level 5 subvolumes in /etc/fstab will be created with new backups, nested subvolumes will be created and can also be removed/added in an update of the backup img.
Please read Info section for more information.

Autoexpansion tested & supported on following operating systems:
- Raspberry Pi OS (trixie and older)
- Armbian
- Manjaro-arm
- DietPi
- ArchLinux-arm
- Kali-arm
- Ubuntu-server-arm (Ubuntu autoexpands by default, but that can be disabled with -e option)
 
Autoexpansion does not work on f2fs due to filesystem limitations.
Other operating systems will most likely work too, but autoexpansion will not.
The script will report the operating system as "unknown" but that does not mean the script will fail.
Feel free to make a feature request if you use an operating system not on this list.

Full functionality for usage inside webmin (including "custom command" button).

Latest release: shrink-backup.v1.4
Testing branch if you want to have the absolute latest version. There might be bugs.

Very fast restore thanks to minimal size of img file.

Default device that will be backed up is determined by scanning what disk-device root resides on.
This means that if boot is a partition, that partition must be on the same device and before the root partition.
The script considers everything on the device before root as the bootsector.

Backing up/restoring, to/from: usb-stick /dev/sdX with Raspberry pi os has been tested and works. Ie, writing an sd-card img to a usb-stick and vice versa works.

Ultra-fast incremental backups to existing img files.

See wiki for information about installation methods, usage and examples.
Ideas and feedback is always appreciated, whether it's positive or negative. Please just keep it civil.
If you find a bug or think something is missing in the script, please file a bug report or feature request

To restore a backup, simply "burn" the img file to a device using your favorite method.

When booting a restored image with autoresize active, on some operating systems a reboot will occur after resizing is made (you will be informed at the end of the script if your operating system is affected by this), please wait until the the reboot sequence has occurred. The login prompt may very well become visible before the autoresize function has rebooted.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Usage:
 
shrink-backup -h Script for creating an .img file and subsequently keeing it updated (-U), autoexpansion is enabled by default Directory where .img file is created is automatically excluded in backup ######################################################################## Usage: sudo shrink-backup [-Uatyelhz] [--fix] [--loop] [--f2fs] imagefile.img [extra space (MiB)] ------------------------------------------------------------------------------------------------------------------------------------------------ -U Update existing img file (rsync to existing img) Optional [extra space] extends img size of root partition -a Autoresize root partition, [extra space] is ignored. When used in combination with -U: Expand if partition is >=256MiB smaller than resize2fs recommended minimum Shrink if partition is >=512MiB bigger than resize2fs recommended minimum -t Use exclude.txt in same folder as script to set excluded directories One directory per line: "/dir" or "/dir/*" to only exclude contents -y Disable prompts in script (please use this option with care!) -e Disable autoexpansion of root filesystem when image is booted -l Write debug messages to logfile shrink-backup.log located in same directory as script -z Make script zoom at light-speed, only question prompts might slow it down Can be combined with -y for UNSAFE ultra mega superduper speed -q --quiet Do not print rsync copy process --no-color Run script without color formatted text --fix Try to fix the img file if -a fails with a "broken pipe" error Will activate rsync options --delete-before & --fsync --rsync Define custom rsync line manually. Will print rsync line for user to edit --loop [img] Loop img file and exit, works in combination with -l & -z If optional [extra space] is defined, the img file will be extended with the amount before looping NOTE that only the file gets truncated, no partitions Useful if you for example want to manually manage the partitions --chroot [img] Use systemd-nspawn. Loop img file, mount to temp directory, enter chroot environment and drop to shell This will let you make changes in a chroot environment directly on the img file For example update with package manager or rebuild initramfs The script will keep running in the background --f2fs Convert root filesystem on img from ext4 to f2fs Only works on new img file, not in combination with -U Will make backups of fstab & cmdline.txt to: fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak Then change ext4 to f2fs in both files and add discard to options on root partition in fstab --version Print version and exit -h --help Show this help snippet ######################################################################## Examples: sudo shrink-backup -a /path/to/backup.img (create img, resize2fs calcualtes size) sudo shrink-backup -e -y /path/to/backup.img 1024 (create img, ignore prompts, do not autoexpand, add 1024MiB extra space) sudo shrink-backup -Utl /path/to/backup.img (update img backup, use exclude.txt and write log to shrink-backup.log) sudo shrink-backup -U /path/to/backup.img 1024 (update img backup, expand img size/root partition with 1024MiB) sudo shrink-backup -Ua /path/to/backup.img (update img backup, resize2fs calculates and resizes img file if needed) sudo shrink-backup -Ua --fix /path/to/backup.img 1024 (update img backup, automatically resizes img file if needed, fix img free space) sudo shrink-backup -l --loop /path/to/backup.img 1024 (write to log file, expand IMG FILE (not partition) by 1024MiB and loop)  
 
Thank you for using shrink-backup ❤️❤️
A backup is not really a backup until you have restored from it.
 
 

Yes, I am working on that.
Whiptail is what I am educating me in closer right now.
 
But it will most likely be it's own script. Trying to implement the script straight up I think would become messy pretty fast, and I don't think anybody is interested in that.
 
But yes, it is happening, sometime.. xD
I was honestly hoping it would already be a reality, but my health keeps putting up roadblocks for me.

There never was a cert since it is just a simple redirect to https://armbian.myspreadshop.net/ so feel free to use this address.

Finally found the better answer to my initial question. The process is described in the wiki:
 
https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader
 
However, there is one mistake. Instead  of the last line
 
~ $ bash pack/usr/lib/u-boot/platform_install.sh pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device  
you need to run
 
~ $ source pack/usr/lib/u-boot/platform_install.sh ~ $ write_uboot_platform pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device /dev/sdb  
In addition it is important to start the partition at block 8192 (at least for my odroid HC2, may be a differnet number on other devices).
This way you can easily write your backups to an sd.
 
Regards,
Jürgen

GPT is something the Armbian build framwork supports, not currently the default, but here is a list of boards that use it:
grep -i gpt *
armsom-sige7.csc:IMAGE_PARTITION_TABLE="gpt"
armsom-w3.csc:IMAGE_PARTITION_TABLE="gpt"
bananapir2pro.csc:IMAGE_PARTITION_TABLE="gpt"
fxblox-rk1.wip:IMAGE_PARTITION_TABLE="gpt"
hinlink-h28k.csc:IMAGE_PARTITION_TABLE="gpt"
hinlink-h88k.csc:IMAGE_PARTITION_TABLE="gpt"
hinlink-ht2.csc:IMAGE_PARTITION_TABLE="gpt"
indiedroid-nova.csc:declare -g IMAGE_PARTITION_TABLE="gpt"
jp-tvbox-3566.tvb:IMAGE_PARTITION_TABLE="gpt"
khadas-edge2.conf:declare -g IMAGE_PARTITION_TABLE="gpt"
mangopi-m28k.csc:IMAGE_PARTITION_TABLE="gpt"
mixtile-blade3.wip:declare -g IMAGE_PARTITION_TABLE="gpt"
nanopct6.wip:IMAGE_PARTITION_TABLE="gpt"
nanopi-r5c.csc:IMAGE_PARTITION_TABLE="gpt"
nanopi-r5s.wip:IMAGE_PARTITION_TABLE="gpt"
nanopi-r6s.conf:IMAGE_PARTITION_TABLE="gpt"
odroidm1.conf:IMAGE_PARTITION_TABLE="gpt"
orangepi3b.csc:IMAGE_PARTITION_TABLE="gpt"
orangepi5.conf:IMAGE_PARTITION_TABLE="gpt"
orangepi5-plus.conf:IMAGE_PARTITION_TABLE="gpt"
panther-x2.csc:IMAGE_PARTITION_TABLE="gpt"
quartz64a.csc:IMAGE_PARTITION_TABLE="gpt"
quartz64b.csc:IMAGE_PARTITION_TABLE="gpt"
radxa-e25.wip:IMAGE_PARTITION_TABLE="gpt"
rock-3a.conf:IMAGE_PARTITION_TABLE="gpt"
rock-5a.wip:IMAGE_PARTITION_TABLE="gpt"
rock-5b.conf:IMAGE_PARTITION_TABLE="gpt"
rock-5-cmio.csc:IMAGE_PARTITION_TABLE="gpt"
station-m2.csc:IMAGE_PARTITION_TABLE="gpt"
station-m3.csc:IMAGE_PARTITION_TABLE="gpt"
station-p2.csc:IMAGE_PARTITION_TABLE="gpt"
xiaomi-elish.conf:IMAGE_PARTITION_TABLE="gpt"