Igor

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

I guess that doesn't take 50-80h from your every day? And you probably don't have thousands of users pushing on round the clock to fix this and that and asking how to run a space shuttle on a 15 USD device? Finding bugs under such circumstances? I can easily blow whole day just for giving you tips that you don't waste weeks, just days, while children are running around the house 1/2 of a day, then 1/3 of the time needs to be secured to pay for the bills. Including yours. Project costs are not near covered by donations. We have to add majority. When you pull out full blown ma

This is going to be fixed hopefully before next major release https://github.com/armbian/build/issues/2398 We have notice this problem but it seems to be related to some Debian library. There are so many problems and so little time ...

That is expected since they take someone image (probably its armbian in this case) and repacks it with their branding and few bash scripts.

Not really. I tried to find one ... native compilation on arm64 build machine might work, but that is under development and also not supported method https://armbian.atlassian.net/browse/AR-457 Can and do breaks for other reasons.

Known problem / almost fixed. That's by the design of this S3 service. https://minio.k-space.ee/minio/armbian/

Currently broken

We have no time and absolutely no budget to cover bugs on this very buggy hardware. Officially Armbian don't have any maintainer(s) for this board anymore, so its basically a community supported, as is. @Pali is trying to bring up mainline u-boot support and that's about it. Don't know how far things are and if upgrading u-boot helps in this case. It's only alternative, so worth trying. This is just a bug like any other - moved to bug tracker forums. You couldn't choose worse hardware So help.

I found your post on Google while looking out for why Bullseye root creating is breaking. That's primary motivation of my comment. Second is pointing out that we will not even try to fix anything in this area even I tried to find a workaround. And I actually need to remake those cache files by hand ...

qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) Yet another Qemu bug which crashes second stage of Debootstrap and only on Bullseye arm64. It used to work, we didn't change anything ... unsupported userland, unsupported kernel ... https://launchpad.net/qemu https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=qemu;dist=unstable https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debootstrap;dist=unstable

Yeah, that's it. IMO something is wrong with / around LCD driver. I suspect this - Pine only sells Pinephone, which is the very similar hw, just in different form factor and by upstreaming LCD on Pinephone they break support for Pinebook somehow ... Since we already lost several afternoons trying to fix this it is unlikely to repeat that anytime soon. Not possible

Support project https://gitlab.com/open-transmit/transupdate

And you will kindly cover costs of that investigation? And all those we already did but failed to fix anything? Or at least do something we need? Legacy images with kernel 5.4.y works https://armbian.hosthatch.com/archive/pinebook-a64/archive We'll remove 5.10.y from download section.

Agree, but on 3000+ USD NAS, things ain't much better Client is high-end workstation running Mint, 10Gb connection ... 138.4MB/s 224.29MB/s ... while NFS transfer speed is normal: IMO hardware performance is just fine.

So we have a bug related to armbian-config ... hmm.