Werner

I was thinking of asking the same question.
 
Personally my feeling is if you are planning on helping Armbian by working to incorporate your efforts back into Armbian then I strongly encourage your efforts.  But I would recommend working with the Armbian developers on how you plan to do this, as it can be frustrating for you if you put in a lot of work into something, only to find disagreement from the Armbian community about how you are implementing something that might prevent it from being accepted.
 
If your intention isn't to incorporate your work back into Armbian, then you are creating just another fork (like the many that already exist), which you are entitled to do since this is open source.  But in that case I would request that you not use the limited Armbian resources to do that (i.e. our developers and infrastructure like these forums).  These forums are for Armbian developers and users, not for use by forks of Armbian that just attempt to take from Armbian without contributing back.

This will be a fork that will return the code to the parent project https://github.com/armbian/build ?
Or is it planned to be developed as an independent project based on this branch?

We don't know if it works perfectly. We cannot afford doing extensive testing. We rely on user feedback in that matter.

bad sdcard isn't uncommon. One of the two first aid things to check if something is weird is switch sdcard to a known good one. The other is switch psu

IIRC he prefered to stay independent which I understood. Though that was a year ago where his motivation was still high.
 
Now things have changed. We told him he'd be more than welcome to join forces and share the burden.

As you have mentioned in chat you tried this with mainline 6.10.y which I don't expect to even work. Support for rk3588 soc is still under heavy development and I don't think anything NPU related has been pushed upstream yet.
 
You should try with 6.1.y vendor kernel. Why? https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

moved to tvboxes

Thank you very much.
I collect in a notebook all possible bugs when using this utility.
I want to redo it.

Omg! 😮 A TV box with fake memory!
Now all that's left is for you is to discover that the original software has malware 😅 
the first rule on TV box for Linux is "don't trust TV boxes"
stop been scammed and buy a board from Partners
My personal favorite is Bpi
 
this information was on media since 2023, you need to take care.... https://youtu.be/1vpepaQ-VQQ?t=445
 
 

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

Why not search forum first? There was smth similar few days ago

Just guessing. Sometimes armbian-install seem to fail to populate /boot or the UUID of the nvme is wrong.
Try this: clear mtd and nvme, boot from fresh image from microsd, maybe remove emmc if not needed.
 
Do armbian-install and let it move OS to nvme and flash spi.
Do not reboot. Mount the nvme again somewhere and check if /boot is populated. If not, copy everything manually from microsd/boot to nvme/boot, then use lsblk or similar command to get the uuid of the nvme and edit the freshly copied armbianEnv.txt to match the uuid.
If /boot on nvme is populated already make sure the uuid is correct.
 
Then shutdown, unplug, remove sd and power up again.
 
For best chances debugging boot issues set verbosity to 7 in armbianEnv.txt and check the video at https://debug.armbian.de
 

Just guessing. Sometimes armbian-install seem to fail to populate /boot or the UUID of the nvme is wrong.
Try this: clear mtd and nvme, boot from fresh image from microsd, maybe remove emmc if not needed.
 
Do armbian-install and let it move OS to nvme and flash spi.
Do not reboot. Mount the nvme again somewhere and check if /boot is populated. If not, copy everything manually from microsd/boot to nvme/boot, then use lsblk or similar command to get the uuid of the nvme and edit the freshly copied armbianEnv.txt to match the uuid.
If /boot on nvme is populated already make sure the uuid is correct.
 
Then shutdown, unplug, remove sd and power up again.
 
For best chances debugging boot issues set verbosity to 7 in armbianEnv.txt and check the video at https://debug.armbian.de
 

ah. good old omv annoyance. Known to mess up the system....

I think so, yes. As mentioned Armbian kernel comes with wireguard module pre-installed so nothing besides the userspace tools is required IIRC.

Ah yeah, now I know.
You are installing with recommends which might include wireguard and wireguard-dkms packages which have dependency on stock Debian/Ubuntu kernel which then will be installed and render your system unbootable.

1. Script build all changed packages every 4 hours or manually in-between:
https://github.com/armbian/os/actions/workflows/complete-artifact-matrix-all.yml
2. If this is successful repository rebuild follows (rolling and stable)
https://github.com/armbian/os/actions/workflows/repository-update.yml
3. Once finished, packages are pushed to rolling release repository http://beta.armbian.com (which is stable enough for this hardware and most of end users). As kernel covers many devices, pushing to default stable repo https://apt.armbian.com happens manually after observing this https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results
 
None of other distributions or distributions provided by vendors have this kind of quality control. Sadly, not even this is enough, but better we can't afford.

Without proper logs this hard to track down. Try to grab some actual logs when you get a chance: https://debug.armbian.de
 
Wireguard is - kernel-wise at least - nowadays included in all Armbian images. However it might be necessary to install userspace tools separately (i.e. apt install --no-install-recommends wireguard-tools), especially on minimal images.

Search for "H6" in this section.

Releasing packages on repo was purposefully delayed for a good week in order to keep with another expectation you have - that release software is well tested  What we help here is to lower % of breaking your old installations by delaying with releasing packages so images gives additional round of test resoults. Testing of one release exceeds budgets for hundreds  if not thousands of times. If you don't help with testing, its impossible to test. And you don't / very little. There is nothing we can do and only everyone of you can improve this. If you want better service, step up, help us maintain some small part, perhaps automation for repository management? Which is related to your problem. More people, better organisation, faster and better will be updates ... or at least not worse.
 
https://github.com/armbian/os/actions/runs/10762581915
Once this is finished with success, packages will be uploaded to the repo:

https://github.com/armbian/os/actions/workflows/repository-sync.yml
Then few cycles of repository synchronisation:
 
https://github.com/armbian/os/actions/workflows/redirector-update.yml
Followed by re-director update, which serves, in theory, only mirrors that are up to date:
 
Someone needs to help maintaining this mechanism. 

If you expect drivers going up with the kernel, then you need to help here:
https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh

Thanks Werner, I initially misread it. Corrected it already.

Board is not a supported Armbian SBC, moved to the Community Maintained forum section and reset the board tag to reflect the correct board.

I will check it to find what's wrong. Unfortunately it might take some time since i don't have any 2k screen

Logs excerpts are usually useless. Provide logs as suggested from the build output:
Try to build from main instread (I assume you tried 24.05 branch)

Pre-made images for download are compressed while building an image by yourself is not by default.
use xz to compress it and you should get to your desired ~250M