langerma

Hi all.
I'm working on a script that can install different Linux gaming tools like Box86, Box64, PPSSPP, ...
For now it can only install box86 and box64. There is also an issue installing wine, so this doesn't work either.
 
https://github.com/NicoD-SBC/armbian-gaming
 
Download and unzip and run script : sudo /bin/bash ./armbian-gaming.sh When ready I'll make a video about it and give more info.
 
I've tested it on the PineBookPro with Hirsute.
With the Odroid N2+ you need to activate panfrost, install dependecies for N2+, and then install box86. Tho it didn't work as it should.
If "install box86" gives a build error, try the dependencies for N2+ and try "install box86" again.
 
Please let me know your experiences on other systems.
 

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
 
 
 

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
 
 
 

If Helios/Kobol is out of business - What "specs" should I use to define a replacement board - a rockchip 3399 board with the dimensions ?
 
Help please -- (I'm getting an increased number of memory errors and of late an increased number of USB faults)

I'm running (at the moment) - the system as a simple NAS with exported NFS4 volumes - the entire lot of 5 drives are formatted at BTRFS -- I'm working on archiving the data off and once done I'll format all as ext4 and try using simple RAID. 
 
Rich Leonard

@ams.br seems like your patch works!

at a Linux OS (Armbian recommend Ubuntu), download the latest source of armbian build
git clone https://github.com/armbian/build.git copy patch file arm_arch_timer.patch to folder userpatches/kernel/sunxi-next (more details in documentation). Run the compile script
./compile.sh choose "U-boot and kernel packages", apply.
 
choose "Do not change the kernel configuration" for a standard kernel, or "Show a kernel configuration menu before compilation" for customize your kernel (recommended for advanced users), apply
 
choose your board
 
choose "next"
 
apply, and now just have a coffee and wait. After compilation deb packages generated at folder output/debs, copy the deb packages to you Armbian and run dpkg -i *.deb
 
more details at https://docs.armbian.com/Developer-Guide_Build-Preparation/
arm_arch_timer.patch