Igor

We just change status since we are unable to take care of it anymore. There are archived images for emergency. They will boot. Upgrade - we can't provide warranty. When we stop investing our time into supporting hardware, it usually starts the journey of falling apart. Upstream changes can break once this board, then another one or some of its vital functions. This is happening all the time. Unless you are o.k. with frozen kernel and no upgrades ... In this case it is just a very direct symptom - not booting at all. Keeping all SoC functions alive and functional is another level. This board is now like Debian, Arch, Manjaro, ... supported, works in theory, but ... you have to fix it in case not. This forum will help on best effort, but we can not provide any dedication. Its about taking the load away from people that work 24/7 on this project. We have to drop support since we have enormous of other work, new HW is coming all the time. I waste 4-6 hours every day just for talking and planning without any touch with HW. Playing with hardware is usually more fun, but no time. Time and managing capacity is the problem. Current test facility is basic and simple. Trust me. Also no need to understand it - it is currently used to estimate overall support state. As a maintainer you should know if it works or not - that is among job descriptions. A spare hardware would be nice, yes, so you don't use production HW for upgrade test and similar. I can send you some hardware, not this one, since I don't have spare, but something else. In case you are interested? I am afraid its false positive Bug in error detection in first step. I made this script and I fix it when I find time. But there are other more critical problems all the time https://github.com/armbian/scripts/runs/5629245369?check_suite_focus=true

More reviews are waiting https://github.com/armbian/build/pulls 👀

After this is merged, we are going to produce images by default when making a pull request labelled with "desktop". A combination of those desktop images are created: matrix: board: [uefi-x86,rpi4b] release: [focal,bullseye,jammy] desktop: [xfce,gnome,mate,cinnamon] ... it takes around one hour after PR is approved. Artefact download page looks like this:

source /etc/armbian-release apt install linux-headers-${BRANCH}-${LINUXFAMILY} Otherwise https://docs.armbian.com/User-Guide_Armbian-Config/ Which will most likely fail since this is not official Armbian build.

A few of ready to merge but needs someone attantion: Build images on PR if label is set to "Desktop" Fixing deprecation notice for our primary key Refactor all PPA sources due to apt-key deprecation

We upgraded kernel and probably DT name changed. (without looking into the code) Welcome! For start it would be ideal to take this role related to this particular board, which currently doesn't have anyone. Or this. We also have a board in test facility.

Usually this is a temporally problem. No need to change to specific mirrors. Problem is: deb https://apt.armbian.com/ bullseye main bullseye-utils bullseye-desktop APT re-director has issues with that and we have some dirty workaround in place ... which is not working best. New solution is in development. BTW. Full mirror list: https://github.com/armbian/mirror#packages

Sorry, didn't get HW nor have time to peek into. In a few weeks would be best guess.

Better try here https://github.com/GloDroid/glodroid_manifest/issues

CSC targets does not have maintainers. My name was there by mistake. Fixed. https://docs.armbian.com/User-Guide_FAQ/

If you already have grub, DD-ing partition will also work. But, yes, this hacking is not very user friendly and has to be sorted out.

This part is under construction. Its pretty much turnkey live build. If you plan to run it from USB, you just flash and run. I do this for two build runner machines where internal SSD is used for data storage (KVM images). Boot from USB is more then enough. When I was installing Armbian on Threadripper I burned image to USB key, boot from another and DD Armbian directly to SATA boot drive. So I had a fresh start with auto expansion to that boot drive. Which is 64Gb SATA SSD. Those are viable workarounds for now ...

Done. Thank you! https://www.armbian.com/banana-pi-pro/ https://github.com/armbian/documentation/commit/b488955daf952fc8b53db4d2ee4a633bd9096f14

https://github.com/armbian/build/pull/3548 Since we have more then one beta server we need to sync them before making images.

Review needed. https://github.com/armbian/build/pull/3552

Strange. Make a pull requests with a note that its not operational / WIP state. P.S. Thanks!

Lets say it is desirable that someone from specific group checks the code, but in most cases this review should at least check for most obvious troubles any developer can spot, perhaps propose changing approaches in scripting, coding style. I don't expect Rockchip / Allwinner / * specialist will be able to see that some patch breaks some functionality. This is a job of automated test routines on hardware. Which is very much WIP but that's what we can afford ATM. If we engage more people to view the code before merge, we made a step forward. And that counts! It doesn't need to be a regular team member. Anyone with a Github account and some time and interest to help us code better is welcome to comment and slow the process of merging. I think we also need to create a protocol for emergency merge / corner cases.

As our projects grows in size and complexity it is getting more and more important to add additional measures to improve code quality. Code is added almost daily and therefore we have to do what is possible to improve chances that things doesn't break or have obvious bugs. Therefore I propose to enable additional conditions applied to the build framework master branch: - code must be submitted via a pull request - pull requests require at least one review and approval from another individual - all changes open requests resolved before merge. - in-line conversation on merge request has to be resolved before merge - commits pushed to master must have verified signatures, - conversation on merge request has to be resolved before merging. @private/contributor Most of the things we already use, so new thing is mandatory review - counts from anyone except from the one that is sending a pull request. Speak up if you find those measures too draconian. Also I would like to point out another change related to our label system. It seems too complicated, some tags were never used and not many people are using them. So limiting them down significantly - comments are welcome here https://armbian.atlassian.net/browse/AR-959

- workaround can be found in manual or by searching this forum. - solving this problem is an expense. Supported or not supported hardware. Its general problem, so ticket was opened: https://armbian.atlassian.net/browse/AR-1116 Look how many problems there are - which is one of main reasons why this board is not supported anymore: https://armbian.atlassian.net/jira/dashboards/10000

I can only tell you that Orange pi 3 LTS board is not supported in Armbian (or any other distro) yet. HW is different enough that it can't just work with the code for non LTS version. Certain things has to be ported to the modern kernel that we use. But that never starts without hardware on the desk and other necessities such as time. We need to get them to the lab (they has been sent out from China last week), redistribute to people that want to spent their precious time talking with users problems and whispering to the hardware.

workaround: download file from https://imola.armbian.com/beta/pool/main/l/ install with sudo dpkg -i FILE.deb and DTB package. Headers are optional - if you need to build modules.

Yes, until we don't find time to fix switching and then when life permits check why SPI doesn't work. Sadly we are not in a position (far away) to check if all functions doesn't break on upgrade ...

Fixed https://armbian.atlassian.net/browse/AR-1107

https://github.com/armbian/mirror dl.armbian.com and apt.armbian.com are picking them. Problem in this case is that TV boxes are unofficial hacked builds which might not work with all armbian tools. https://www.google.com/search?q=list+all+files+in+apt+repository

List is added at build time while your image was made before https://github.com/armbian/build/commit/bd3609b4d1d9c5402d111357b6e394025075cc98 yes