Jump to content

Igor

Administrators
  • Posts

    13936
  • Joined

  • Last visited

Everything posted by Igor

  1. Armbian framework nor those packages we make are not / should not be touching this, but we could perhaps patch this behaviour if you provide more context, do additional research. How this can be reproduced, where (Jammy, Noble, hardware X, desktop Y) this happens, etc. Without supplying logs, developers needs to use black magic Personally I don't practice that and BTW, I use ZSH.
  2. As its optional (user defined) part of the codebase. This was the decision why its generated at 1st run.
  3. Probably your system time and date is / was invalid, in future. In any case, not something special to Armbian. All Linux systems uses same base software.
  4. Please ignore Ubuntu kernel versions as they are not relevant here. We only use their user space package as its a bit of nonsense to build all those packages from sources on our own. Ubuntu declare LTS support for whole distro. We use packages with long term support combined with our kernel. Which I believe is a perfect combination. Especially in ARM hardware world where Ubuntu kernel can't match with us. As @going also exposed, we look to kernel org and there, latest LTS is 6.6.y ... which we ship with most platforms. There is no more recent one. 6.8.y is not LTS, but its in fact End Of Life. For everyone. If Ubuntu says otherwise, its probably decision of their marketing department. We ship LTS Ubuntu distro with kernel we select and maintain. It is in almost all cases kernel.org latest LTS + our work. Focal userspace (Ubuntu 20.04) is a bit old and it is not so well maintained anymore (by Ubuntu) as they claim, so we decide to stop providing it. We have no interest nor resources to maintain that very old packages instead of them. Kernel 5.15.y is also slowly going out and I would not recommend to use anything lower then 6.1.y on sunxi platforms.
  5. Kernel is taken from www.kernel.org (or from hardware vendors or some other places) and it is heavily modified. Armbian build framework flexibility allow us to ship any combination of user-space with any kernel. We choose what is best, but you are free to change it to something else. We have very little with Ubuntu or Debian when its about kernel. Latest version, stable / LTS user space (in case of Ubuntu smell, rather Jammy then Noble), current kernel. Otherwise, in general, this is custom hardware world - depending on hardware and use use case. Always. This is still valid to this day: https://docs.armbian.com/#what-is-the-difference-between-armbian-and-debianubuntu Armbian kernel lives its independent life. We provide Linux distribution that looks and its compatible with Ubuntu or / and Debian. So you can follow instructions as such https://www.digitalocean.com/community/tutorials and they will work perfectly the same as Debian / Ubuntu. You just need to match upstream Debian / Ubuntu versions. That is Armbian release version: https://docs.armbian.com/Process_Release-Model/#release-naming This is build log for one such release, so you can see what we do: https://docs.armbian.com/Release_Changelog/#v2451-2025-25-5 Which usually include latest LTS version of Ubuntu user space + Armbian kernel or latest Debian stable + Armbian kernel. Our focus is hardware support which means hardware interface on our Debian and Ubuntu is binary identical and also significantly better then from what is shipped by Ubuntu or Debian. Armbian Jammy and Armbian Noble = assembled from Ubuntu user space applications packages., Armbian Bookworm and Armbian Trixie = assembled from Debian user space applications packages. Does this answers your questions?
  6. We are well aware that our download pages are no perfect and generally there is always room for improvements, so we are constantly trying to improve them. Better UX and useful information saves time. Help us saving your time! Things like: https://armbian.atlassian.net/browse/AR-2363
  7. (Armbian) Linux kernel is a common work, product which we maintain in certain areas so you can run Linux on those devices better. Defaults are also where our best effort "warranty" ends - this can be checked with automation, manual testing of *all features or even fixing them is impossible. Linux kernel is a complex machinery and a work of tens of thousands of people. Nobody really knows if feature you are trying to get working in the kernel builds or not and if it works at the end. Ready (def)configs are usually made with a reason that you start with a known-to-work configuration, proceed slowly and fix things on your way. Similar as we do in some areas. Keeping this code build-able and in good shape is already on the very extreme expense end. This is open source and all work is public, value can be reused by everyone, sadly also by competitors that contributes nothing, hardware vendors also don't just help out of humanitarian reasons because we help you using their products. Code quality in Linux kernel is different. Especially if we are talking about vendor kernels. There, only HW features are maintained, nothing else, so this difference is just extreme. But also in mainline Linux, code is usually build-able & usable only until maintainers (largely amateurs) are doing their hard work. Dead and orphaned parts of code are regularly removed, but this functionally deprecation is a process that takes time, a lot of code is broken for long time, decisions are arbitrary. We don't do that as we don't have capacity for patching this megalomaniac chunk of code. We leave things as is. Only upstream Linux does that in small %, here and there, and even they are considered small and under-powered. Most of people in Linux (FOSS) land are sadly not maintaining critical infrastructure such as kernel, but doing some "me too" spin, copy of copy, Linux distribution. Shipping someone code is significantly cheaper that developing and maintaining it. When you start doing what you do, things can quickly become messy and unpredictable. Armbian framework, infrastructure and this community can't do miracles, but provides added value. It doesn't make things worse and that is already a great achievement.
  8. It is. We even use a few of those machines to host build runners. Docker documentation is largely outdated. Now its does everything automatically, but you need to install Docker itself IIRC.
  9. Kernel 6.8.y is hit and miss. We need to separate download links somehow ... for now it was added "Kernel 6.8.y is at experimental support level! Not all features work but it runs fairy stable." to warn you. Its good to be there, as they are usable - where they work. I run several github runners on Rock5 without any troubles for months.
  10. This is probably some (temporally) network issue. Infrastructure shows no signs of troubles.
  11. This. I think the shell / concept is done and adding this should already be possible, but from scratch. We try to get rid of that old spaghetti code that is in old armbian-config. I am not very up 2 date on what is going on there. @Tearran and @schwar3kat are trying hard to push it further and perhaps they can give you some hints how to add this section. Yes. That the idea.
  12. apt.armbian.com is published at point releases, from this branch https://github.com/armbian/build/tree/v24.05 If you check it out, you will get identical what is on stable repository. If you want to go manual way, here https://github.com/armbian/build/blob/v24.05/config/sources/git_sources.json are information about sources. beta.armbian.com is published every x hours from trunk https://github.com/armbian/build If you want to see how this is done, peek into this code. Kernel 6.8 and 6.1 are very very different. Don't expect 6.8 to work better or that all functions will work. Some are not even developed - it is being developed from scratch for around two years now. Code is changing fast, so there is not possible to provide any support. Its too expensive and useless. If you want dig in, but expect troubles and very little response as not many people deal with. 6.1 is different. All 3588 share same problems ... more or less and there is a lot of support in forums.
  13. Can you provide a package or a file associated to this library? So we can find it and add.
  14. There are some issues with Helios64 patches for 6.9.y https://github.com/armbian/build/pull/6691 Please check notes.
  15. Not anymore ZFS, versions that we are adding is now again properly autotested: and this won't be happening in the future. If dependency check fails, packages are not pushed into the repo ...
  16. This is certainly not deliberately and will probably be fixed soon. Open a bug and / or report here.
  17. https://armbian.atlassian.net/browse/AR-2192 Fixed in latest release.
  18. Change to "vendor" kernel 6.1.y is recommended.
  19. I have (hopefully) fixes ZFS on all variants yesterday, but haven't tested on Debian yet. Works fine on Ubuntu based builds, ZFS v2.2.4. If you have time to test, beta.armbian.com should have proper packages: https://k-space.ee.armbian.com/beta/pool/bookworm-utils/z/zfs-linux/
  20. Here you can make a donation. Thank you. That "Ubuntu" was in 99.99% developed by Armbian and other open source projects. Orangepi is HW dealer. They only care that hw features works. They never pushed fixes to common code. We have to spent our private time if we want to port / fix their HW bugs & features to better common code which is the only one maintained and which is in your interest to run it. Software you are so happy to use is on this level. We are maintaining software together and this issue was not closed. Do you really believe unmaintained promo software have only one problem? 😁 There is a new release out tomorrow. Every download page has daily assembled images with latest updates and fixes, where you should check if this problem was resolved. Did you check that before?
  21. That is O.K., but Armbian build framework does not accept HW related tickets. Forum is right place where you can bring this up and discuss what to do. Then open a PR if solution emerges ... Without this patch, PCI probing will randomly fail. Which is worse then 100% going up in 1x. This is my 2c. I understand that you would like to have a perfect functioning PCI system on this hardware platform and if you cover someone several weeks of R&D, this can probably be done. Since this will not happen, we have partial solution/workaround in place, this forum and we have each other.
  22. Or install attached with dpkg -i armbian*.deb armbian-config_24.5.0-trunk_all__1-SA8477-B2b14-R448a.deb
  23. Perhaps this is a solution? https://github.com/armbian/build/pull/6652
  24. Planned point release and images rebuild date is upcoming Saturday, 25th. There are three problems, that would be nice to fix before. People working on are very busy and might not be able to deal with, so help is needed here: Debian bookworm XFCE lacks wallpaper and lockscreen Compile from sources and pack Chromium for aarch64 on PPA Resolving Noble incompatibility with amazingfated-rk3588 extension Thank you all that participated in this release!
  25. Two desktops needs additional testing: https://github.com/armbian/build/pull/6626 https://github.com/armbian/build/pull/6625 ... we are high on closing existing tasks and very low on time dealing with this. There are several other bugs that needs attention: https://www.armbian.com/participate/
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines