Werner

@private/contributor 
 
Unifying TAGS as much as possible - as low count / universal as possible has been enforced to GitHub merge requests and issues. From now on, we have only 12 labels:


 

Then yours probably is not named with a color but with purpose. Simply try adjusting all of them and see what happens. You cannot do any harm doing so.
My best guess would be the user-led ...

Release is not just freezing the code and generating images. Its a time when we pull together stronger, agree and deal with common goals and ideas. Things we are dealing with are complicated. Linux is complex, our framework is getting there too and only together we can deal with all this.
 
I started on freezing the kernel version. There is also some breakage, some related to our patches, some not. But since we have to freeze it sooner or later, perhaps now its the right time.
 
This brings a few good things at once:
temporally release people that are working close with maintaining kernel code @going@jock@balbes150@amazingfate myself ... this can bring more resources on trying to match with / merge armbian-next. @rpardiniworked for moths on this. Lets review the code and help sorting out bugs. Again. IMHO it is possible to merge, but if code remain unstable by the code freeze date (2022-05-14), we are merging after new images are generated. asking @Contributor/Maintainer board maintainers to engage in images building and testing (currently still from master branch) and bug reporting as earlier as possible (once PR 3736 gets merged) reproducible build framework in release branch. Which is most important long term consequence. Additionally, we would like to finish u-boot upgrade on Rockchip and release major forum refactoring @TonyMac32 @piter75 @balbes150
 
Happy Workers' Day!

Or I guess Balbes support is free and easy.    
 
Note this is balbes and not official support status

I assume Balbes will mention if BT is functional in other kernels than legacy...
 

Thank you Werner and Igor,
 
Your valuable commitments and all you've done here is very commendable indeed!
 
Kind words, and grateful for the advice.
 
Best,
Alistair

Only general development on rockchip64 family. However since Helios64 has no maintainer changes there could also break functionality.

Try to install manually to get an idea about what is wrong.
The armbian-config tool basically does this when selecting tvheadend for installation:
 
https://github.com/armbian/config/blob/c9a9b494c3069807471bb00c0336566cd186f6d9/debian-software#L615-L635

Should, yes, but doesn't. RK3399 has an internal fixed boot priority which is something like SPI - eMMC - microSD - NVMe. This cannot be altered.
Armbian works around this by installing a boot loader to eMMC which points back to microSD and if that fails continue to boot from whatever is available instead.
If there is a boot loader on the eMMC that does not do that you have a hard time. That is why pbp installed an internal switch to disconnect eMMC from power to allow microSD to boot.

Both.
https://docs.armbian.com/#what-is-armbian

moved to offtopic since I assume you do not need any help with that.

Here's some info on armbian-next status:
- In development since October/2021 (thus 7 months)
- Currently sitting at 189 commits, almost all lib/**/*.sh files are changed.
- More than 17 rounds of manual merges performed manually against master. Sometimes we have 1-2 weeks of delay, but it's mostly master-equivalent. Each round takes 2-5 hours of carefully reviewing every commit that landed on master and maybe rewriting it.
- Huge changes around logging and error control. Errors now stop the build. Logs contain actionable information.
- Rewritten kernel building and packaging. There's no more packaging patches or builddeb hacks. Kernel-headers support cross compiles across all arches. No more byteshift patch. Still needs tuning.
- Completely changed git handling, specially for kernel. This still needs handling of previously git://, now http:// bundle downloading as reported above, and caching.
- Patch hashing is half-rewritten, still needing work. Now same code can both actually patch and produce hashes, making it consistent. "fasthash"
- apt-cacher-ng configuration for local usecase is now under Armbian control.
- 100% working without any external/downloadable toolchains.
- full support for building any arch under any other arch, including "reverse cross-compiles" and running of rkbin/fip x86-only binaries.
- source code is now properly formatted according to shellfmt, and 90% of shellcheck warnings are squashed. A lot remains still.
- 20x faster kernel rebuilds, 2-3x faster full builds due to consolidated make invocations, benefitting from bintree caching as well as ccache.
- most compression points changed to zstd, yielding multicore (de-)compression and thus much faster image building during cache hits.
- full support for DKMS modules, eg nvidia-drivers and ZFS, under any cross compile scenario.
- data channel for metadata communication, config extraction, matrix generation etc by having stdout clean for machine data. logs to stderr.
- per-build TMPDIR affecting and protecting all `mktemp` invocations
- all traps rewritten under a cleanup/trap manager.
- full HTML-based, single-file, full build log artifact. no more output/debug.
- many others I forget.
 
All that said, I've still a ton of stuff pending before this can 100% replace current master:
- EXTRAWIFI-style manual patching of things is not idempotent nor proven working with "fashhash" and probably causes full kernel recompiles, negating previous benefits until fixed.
- (server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.
- kernel-headers will probably be unified with kernel-sources, since they contain mostly the same stuff.
- extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.
- certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

Some few brave souls like @NicoD, @Rich Neese, and @going have actually tried armbian-next and every single try there's stuff to fix, thanks for trying and reporting.
TL,DR: armbian-next is doing well, thanks. Work continues. It might not be ready for merge, will it ever be? I will keep it rebased as much as possible. There's no pressure. Try it out, and report. Thanks!

 

We have some issues with the redirector. You can work around this by setting a random mirror from the list in your apt for now.
https://github.com/armbian/mirror

fixed

OP is using Jammy.
 
I don't know why this package is no longer part of Ubuntu or has been deprecated with Jammy.
Also keep in mind that Jammy is not stable yet. It probably will in a few days though.
 
It all depends on how much you really need this package and what is more important to you: having this package or having the most recent available OS.

Per the box specs this box should have an alwinner h6 cpu, so moving to the correct sub forum.

Samples arrived ♥️ HW looks fascinating, Armbian is yet to be ported so can't comment how good this is in realworld. Its shipped with stock Khadas Ubuntu, kernel 5.4.y, which is good to boot something ...
 
Technical specs at CNX.

Moved to P2P help.
As with all 3rd party images they should be used with the necessary care.

You're probably going to need to be a little more hands on with the tool you choose.    
 
I like borg and borgmatic.

Because it often enough has happened that user did unknown modifications and blame us for their mistakes. Therefor only official images are supported.

Happy to say that I'm posting this via my pi!

It seems to me like outreach efforts over the years (by people like @NicoD, etc.) have been putting us on the map.  I also tried to help get the word out on last release announcement, which ended up being picked up / re-posted more places than ever before (including LWN, Tom's Hardware, r/linux, etc.) which I think probably helped, too.

Merged three posts. You may want to use spoiler ( ) for longer posts to reduce overall topic length.

Woops! I do apologise! Didn't even think about that!