Igor

Open source projects like ours operate with very limited resources, and infrastructure such as mirrors is maintained on a best-effort basis. We’re aware that things are not always perfect, but addressing this properly requires dedicated maintainers - something we never had. If you’d like to help improve the situation, we’d genuinely welcome someone stepping in to take ownership of this part of the infrastructure. Improving scripts to make this information correct and other things that are missing ... Perhaps contanting mirror owner would already be a solution. I understand - but our mirror system isn’t a standard Debian-style setup. The “empty mirrors” you’re seeing are a cosmetic problem. Only status isn’t automatically pruned yet, so entries can remain listed after they’re no longer active. This does not affect users: traffic is routed through apt.armbian.com and dl.armbian.com, which only serve from working mirrors. What’s missing is automation to keep the public listing in sync - not mirror functionality itself. One of those https://actions.armbian.com/?repo=armbian.github.io needs further development. Our rsync server works: rsync -av rsync://rsync.armbian.com/dl/ I have no clue as this mirror is not under our direct control. Edit: I sent email to administrator of AARNet.

At the begginging of the page https://docs.armbian.com/Mirrors/#introduction it is written how the system works. What we don't provide on that list is current status of which are live in in sync. However you can check this at any moment: curl http://apt.armbian.com/mirrors | jq

Kernel 3.4 was the last known version supporting NAND boot. Since its deprecation nearly a decade ago, equivalent NAND support has not been integrated into mainline kernels.

Did you ran apt update + upgrade + reboot before ? Edit: we might add warning if installed and running kernel version differs. I ran into this problem myself.

They don't provide images for armhf anymore. Last build was 3 years ago: https://hub.docker.com/r/owncloud/server/tags?page=1&ordering=last_updated&name=v7 We made a notice that its compatible for amd64 and arm64: https://docs.armbian.com/User-Guide_Armbian-Software/Media/#owncloud but our installer doesn't filter that out yet. Official Docker way, it won't work. Try something else, perhaps

Did you perhaps upgrade kernel and forgot to reboot?

https://docs.armbian.com/Process_Contribute/#adding-a-new-board

[ 1.234958] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 1.235032] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 PCI support on this SoC has never been fully stable. Patch that tries to mitigate the issue, exists: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/rk3399-fix-pci-phy.patch Not really much we can do more - use a kernel that it works, try current one with few reboots, ... I know its not perfect but we have nobody that can afford investing few weeks trying to fix this. Imagine the frustration if nothing will be improved - which I highly suspect for this case.

We made several test install on Windows 11 and it always worked ... bugs are possible. Best here: https://github.com/armbian/imager/issues And add perhaps more information about the OS, hardware, any special settings that might play a role here. I don't think there is. As far as I can recall, we haven't see this problem yet. Let's ping main developer - if he has any ideas. @SuperKali But as this is a complex software with possible bugs deep down in some libraries, or even Windows itself - I assume you run with all updates?

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

Latest is behind translation: Debian Trixie https://dl.armbian.com/helios64/Trixie_current_minimal with preinstalled OMV: https://dl.armbian.com/helios64/Trixie_current_minimal-omv

https://github.com/armbian/build/blob/main/config/boards/bigtreetech-cb2.conf#L8 Nope. We don't support vendor kernel for other then 3588 and more recent. We don't maintain vendor kernel for this hardware (nor any other 3566 AFAIK), so it might be some work and its all on you. Mainline support is very mature, however I don't know about the status of specific features you are interested in. IMO its not worth going vendor route on this hw.

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.

DKMS compilation per board, examples: https://github.com/armbian/build/blob/main/config/boards/radxa-cubie-a5e.csc#L20-L22 https://github.com/armbian/build/blob/main/config/boards/orangepirv2.wip#L13-L17 https://github.com/armbian/build/blob/main/extensions/radxa-aic8800.sh https://github.com/armbian/build/blob/main/extensions/bcmdhd-spacemit.sh

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.