Igor

  • Content Count

    11291
  • Joined

  • Last visited

Everything posted by Igor

  1. That is expected since they take someone image (probably its armbian in this case) and repacks it with their branding and few bash scripts.
  2. 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.
  3. Known problem / almost fixed. That's by the design of this S3 service. https://minio.k-space.ee/minio/armbian/
  4. 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.
  5. 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 ...
  6. 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
  7. 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
  8. Support project https://gitlab.com/open-transmit/transupdate
  9. 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.
  10. 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.
  11. This basically means you are on your own if things fail. We don't have resources in term of hardware, there are no maintainers or we simply lack of time to spent on problems you have. Via official "board doesn't start way" It's close to impossible to check why this board doesn't boot. Like project gets help https://forum.armbian.com/forum/54-help-wanted/ or better? Merging with the topic in "board bring up section"
  12. Good catch. I didn't notice that and my quick tests on R2S didn't crash the board. Well ... nightly builds already have those patches builds into the kernel. Enable for your board by hand / change in board DT and see if you can reproduce?
  13. synching around mirrors, but already available here: https://imola.armbian.com/dl/station-m1/archive/ https://imola.armbian.com/dl/station-p1/archive/
  14. I will check and fix - I am already in the middle of Bionic rebuild due to a bug and someone reported Nanopi Neo is corrupted.
  15. Seems to be fixed - I couldn't crash it anymore after https://github.com/armbian/build/pull/2567
  16. Its a bug and is going to be fixed with: https://github.com/armbian/build/pull/2573
  17. What would be best at this stage? Assemble some resources to start changing whole app structure, put things together in a better way. Main problem is that script was made in ad-hoc matter and it stayed that way for years. It was never designed to meet the needs. We are just adding things. Armbian config is utility to setup things quicker and an interface with OS low/mid level functions in some more human way. Its not expected that person that wants to help around understands all those functions since the problem is mainly in poor overall design, mixture of different styles, several
  18. Just in case try one version back, older from archive.
  19. It doesn't distinguish between draft and and full pr. This is the command: gh pr list --label "8.beta" --label "7.needs testing" -R "https://github.com/armbian/build"
  20. FYI. Merge requests with labels: "beta" or "need testings" are automatically included in next nightly builds.
  21. I assume you also know how to transfer our current Google form to this one without hours of investigation and much/any functional degradation? Help putting this together is probably more welcome @Werner? Even it's probably not a rocket science. ... and we cover plugin costs
  22. It looks like sufficient support for defaulting ZSH is not going to happen But it will remain as a second choice ... lets repeat this question year later. Speaking on armbian-config ... @tparys started to help on enhancements, I do what I can ... still more helping hand is needed. It's a long term job. Any idea how to get more movement there? Yes, its a wonderful tool, but require constant love. Like other parts of the project.