• Content Count

  • Joined

  • Last visited

Everything posted by Igor

  1. Check this too https://github.com/armbian/build/pull/2552
  2. There are problems with 32bit ZFS support and there is nothing more we can do. https://github.com/armbian/build/pull/2547 https://github.com/openzfs/zfs/issues/9392 Broken od Debian, buildable on Ubuntu based Armbian. At least on latest (LTS) kernel 5.10.y Upgrade to 5.10.y on 32bit target doesn't work automatically ... after reboot you need to run dpkg-reconfigure zfs-dkms and select that you agree with 32b troubles but at the end, it works. I could load my pool without issues.
  3. OK. A compromise is also a good way. A manual transition is also an option since the hardest part is anyway to design the procedure, develop supportive text, form questions. Sometimes copy and paste into a new system is also a good way. We only have one form, which is not very complicated ATM so manual transfer is probably also fine. If suggested plugin covers functionality of course, otherwise someone else perhaps. Since this will probably be the only one we need, we only need some basic functions which means its not justified to go for a most advanced plugin app. It was jus
  4. Few more finds: This module should be responsible: https://cateee.net/lkddb/web-lkddb/CRYPTO_DEV_ROCKCHIP.html Enabled (make sure to use latest version, check config in /boot/) https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config#L8725 modules built: rk_crypto
  5. Now this is officially going away starting March 15, 2021 https://www.zdnet.com/article/linux-distributors-frustrated-by-googles-new-chromium-web-browser-restrictions/ Another blow to the FOSS community. If sync is not going to work anymore, why keeping it?
  6. I assume you have invested at least one hour for searching for this information on the forum but you failed to find any traces of information about hw crypto acceleration within RK3399? BTW. I don't know the answer. I would also need to search for.
  7. Armbian have historically been much more geared towards "server/headless" usage, for many different reasons. It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework. However, this work has been going on in the background for quite some time already. Announcement Finally, the time is right to announce we are publishing our initial implementation of thes
  8. ./compile.sh CREATE_PATCHES="yes" edit source, source, continue copy created patch to patch/kernel/sunxi-current and sunxi-dev ...
  9. They were remaking driver the proper way ... probably this is the case: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts?h=v5.10.10&id=d0c6707ca4235b78d06bcd62f0e24fbeac3e6d10
  10. Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration): it has been stated at the wrong place it lacks fundamental requested data it could have been easily solved by a quick search and/or reading documentation Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate. https://www.armbian.com/bugs
  11. Goal of this form is to guide users to right direction when they notice a problem. IMO there is no need for import functionality. We have one form, which can be manually re-created in case we find a proper tool, ideally with the same functionality we currently use. Also close enough to this is just fine. You also don't need to make everything. We can share this load.
  12. https://docs.armbian.com/#what-is-armbian
  13. 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
  14. 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 ...
  15. That is expected since they take someone image (probably its armbian in this case) and repacks it with their branding and few bash scripts.
  16. 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.
  17. Known problem / almost fixed. That's by the design of this S3 service. https://minio.k-space.ee/minio/armbian/
  18. 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.
  19. 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 ...
  20. 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
  21. 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
  22. Support project https://gitlab.com/open-transmit/transupdate
  23. 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.
  24. 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.