Igor

After years of thinking, wishing and tinkering - Armbian automated WiFi performance benchmark system: https://docs.armbian.com/WifiPerformance/ From latest WiFi 7 down to (in)famous xradio XR819.

For generating torrent files we use: - automatically generated public trackers https://trackerslist.com/#/ lists - web seeds on our servers to secure up to 70 (stable, community builds on around 10) places with 100% file availability Goal for providing torrent download option is maximizing download speed - for you! With torrent protocol, one can not have control where files are and also we don't have own trackers, but we use public ones in automatic way, thus we don't have control on which trackers our files are announced. All files are digitally signed, so nothing to worry about. Edit: if name "pirate" or something else bothers you, here you can submit a fix with some grep -v https://github.com/armbian/os/blob/main/userpatches/gha/chunks/650.per-chunk-images_job.yaml#L139 Perhaps porn and pirate ?

You can check this way: type armbian-upgrade armbian-upgrade is /usr/bin/armbian-upgrade cat /usr/bin/armbian-upgrade #!/bin/bash trap "exit" INT TERM [[ $EUID != 0 ]] && exec sudo "$0" "$@" apt update apt -y upgrade apt clean apt -y autoremove exit 0

Great choice! TBH not many people asked for add this at first run - probably as many use cases are headless / servers and people are used to just run command on their own. But agree, its one of those "nice to have". This is open source world. Anyone can contribute a feature, fix a bug. Donations are here for things that you already have. If you want feature to be fixed or added, line is very long - most of this forum is seeking for something. And there is just a few people on the other side, willing to pay with their private time for the common software maintenance. Donations, what people are willing to pay / contribute, cover less then 1% of the costs. Its a beer, not trade money. End users would destroy the project in no time, if we accept donations as a payment for the work. It is impossible to cover remaining 99%. Here and there yes, long term, no.

Can you be more specific?

From logs I can only conclude that problems are at your side - wrong configuration. Anyone can help you - problem is almost certainly not Armbian specific. May 10 21:05:09 pirogue systemd-helper[8502]: dnsmasq: unknown interface end0 May 10 21:05:09 pirogue dnsmasq[8502]: unknown interface end0 I am not an expert of application you try to install, in fact I never heard about until now.

Many thanks for fixing this! I also tested on my side, works now. We can eventually put this board back to supported list. (board config .csc -> .conf) There are few other things that would be nice to get working - I notice WOL service erroring out, fan support is unknown. I only have PCB without anything attached to it, for testing. Merging both patches shortly.

@Heisath Nice to have you back. I know everyone is busy ... I think speed of this has been brought down in past year and most of changes were on the "must be done" list. Changes generate stress, regardless of their intention. It is getting more and more troublesome - big complexity vs. new devices keep coming out light-speed vs. limited resources for maintaining. We have little to fight this Freshly build image from your patch - doesn't work for me - what I am missing here?

This whole image and config / install script are both very old, unsupported. It has been cca. 5 years since anyone touched code in old armbian-config. We developed new tool, which is fundamentally different and in much better shape. Documentation for old tool never existed. This config tool developed from my personal scripts for installing this and that. And as it was not properly designed, we decided to drop it at some point and develop a proper tool from scratch. You can try upgrading this way: https://github.com/armbian/configng?tab=readme-ov-file#compatible-distributions but no warranty or support in case of troubles. I would tell you to go with a fresh system, but as this image was not made by us, you need to ask vendor to do that for you. Everything that goes outside "Standard support" is usually unknown to the team and also for most of this community. This is custom hardware world, you are running custom Armbian build (probably made by hw vendor). Armbian developers team is super small and it is not realistic to expect support even for limited selection of (custom) hardware that we provide official Armbian builds for. If you just need git tool: sudo apt install git

We just figured out we have dropped packing kernel sources at some point. Until we figure out how to re-enable that or if this makes sense, use build framework to add a custom module. It has the ability to do that. Allwinner kernel is heavily patched, version is not necessarily latest, quite distanced from mainline, while Amlogic, on the other hand, is closer, changed less.

Welcome on board. This will be a huge difference, so be open for learning, have a lot of patience. https://docs.armbian.com/User-Guide_Board-Support-Rules/ One of the key challenges we face is that maintaining older hardware is both time-consuming and costly. With limited financial and community support, the resources we have are already stretched thin across the entire project. Our team is very small—currently, we have only one dedicated maintainer for the Allwinner software stack that is focused into latest 64bit Allwinner family (H6/H6xxx). Other projects often face similar constraints, often relying on a single contributor who can do anything. For example, in our collaboration with LibreELEC (LE), we benefit from some shared efforts, but both sides are still primarily driven by individual volunteers working on a best-effort basis. If priorities shift, progress can be delayed significantly—and unfortunately, Armbian doesn't have the capacity to pick up. I’m sharing this openly in the hope that it raises awareness. Personally, I would love to see continued support for legacy devices. But to make that happen, we need to ask: who is willing and able to invest weeks or months each year required to maintain these older platforms? What you can do? Try to understand how this works, connect with people that share your problem (all similar board owners with interest that it is maintained) - invest time to learn. Probably USB ports are just not enabled - check this: https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays

Remind me. Does WiFi works in image from download section? https://www.armbian.com/download/?device_support=Standard support This (EDGE kernels) raises support costs into the sky and since from open source developers position 99.5% costs are not yours ... use current kernel. Its a huge difference between those two, one has been stabilized, the other not, probably next year, most likely never and will be replaced with next EDGE, 6.14.y with stabilization attempt in more then one year from now. Also legacy 6.6.y would be better for this job. Higher number doesn't mean better functionality and less bugs, often right the opposite. Try this way: sudo ip link set wlan0 up sudo iw dev wlan0 scan

If this is improvement as described, please provide a PR to configs: https://github.com/armbian/build/blob/main/config/kernel/linux-meson64-current.config https://github.com/armbian/build/blob/main/config/kernel/linux-meson64-edge.config Thank you!

Bug in NetPlan / systemd-networkd or bug in Armbian implementation? We have no options to maintain NetPlan or any other similar complex user space component. Armbian uses Ubuntu / Debian packages without changes as we are focused into Kernel space, framework, tools, build automation. If there is a workaround, we can push it somewhere. Like this one: https://github.com/armbian/build/commit/7f32a5853513745ee6aa55b6d3856ac67ec036e2 Forum is just fine. Armbian itself don't have resources to touch any of this, but someone might know something and help you / everyone. I briefly understand what is the problem, but no idea how to solve it.

Armbian is assembled from Ubuntu or Debian packages. If problems is there, problem is here too and there is little we can do about. https://docs.armbian.com/#what-is-armbian We have a mechanism which you can use to insert patched package to our repository, which is in use in some corner cases: https://github.com/armbian/os/wiki Perhaps this is a solution, perhaps not depending on possible dependency nightmare.

First problem was fixed in predicted way. There is no more firmware warnings on upgrade / kernel install. New package is getting to the stable repository in a couple of hours, while it is already present in beta. Agree. While testing kernel, I installed Ubuntu Noble based image and ERROR: Unsupported initramfs version does not manifest there! I suspect this problem is caused by some script that is coming from RaspberryPi OS - on Debian based Armbian, we use userspace and Rpi related firmware packages from RPi OS (which is Bookworm based, so we have great / full packages compatibility). I will try to get to the bottom of this when possible. Basic problem is that in open source and especially in packages assemblies, there are always (tens of) thousands of potentially irritating issues. You noticed this one, we already have a list of many others that needs attention and there is endless list that well always be somewhere ...

Warnings are safe to ignore, happens on other platforms too, but it looks like also error. CONFIG_USB_RTL8152=y -> m should probably do. I will make a config change: https://github.com/armbian/build/pull/8116 I have noticed the initramfs error too, but it doesn't looks it breaks anything. Need to be investigated.

None of those boards are officially supported, so we are not aware on their hw support status. Those are also 32bit architecture, while we only provide 64bit support for Rpi. Did you use Armbian for Rpi? And which particular build? And on which Rpi? There are many unknown things - big difference. Hard to determine the reason from current informations.

Trixie ... let me check and fix this. I only tested Bookworm.

This is around 10 years old (!) demo / beta image that was deprecated cca. 8-9 years ago. If automated builds doesn't work (we can't cover for endless software support for endless ultra-cheap hardware), IMO your best (only) way is digging into https://docs.armbian.com/Developer-Guide_Build-Preparation/ and fixing reasons which are preventing latest kernel / boot loader to work. It might be trivial, it might be hard. Probably nobody knows without research. This will help you http://debug.armbian.de/

This should be fixed, but there might be an error with firmware package. Fix is uninstalling armbian-bsp*, updating all packages, installing bsp againg.

Struggling with repo management for past few days. It would be nice to write it from scratch, but time is an issue

That is wrong approach as we follow kernel source / standards: and this (boot script) contains the mechanism for loading it: https://github.com/armbian/build/blob/main/config/bootscripts/boot-rk35xx.cmd It should work: https://github.com/armbian/build/blob/main/config/bootscripts/boot-rk35xx.cmd#L51-L52 Is your image an upgrade from some old one? As we indeed have issues with this at some point.

Was fixed already.

We provide mainline based kernels via repository. They are up2date with what exists, but support is not complete and also not tested on this particular hardware.