laibsch

Thank you for your continued work on this. Would you be interested to step up as official maintainer for the board, @tabrisnet? @chainsx, what do you think?

The Orange Pi Zero+ is community maintained. That means, there is no guarantee that the device even gets boot-tested. Going through git log I don't see much activity related to this board for the last two years, so quite possibly this is very stale. Current maintainer is @schwar3kat. Maybe he can tell us more if he can reproduce your issue. If you are able to test this board and fix issues to improve support for it in Armbian, your contributions are more than welcome. I do not have the board and am not aware of anyone who owns it.

If I were you, I would first try to get headless working, log in via ssh and fix things from there.

@Eng.ahmedflash Sounds to me like you are mistaking this volunteer effort with support from your vendor. I suggest you redirect your request to whoever you purchased your board from.

@Piotr Kędzia Have we found ourselves a future Orange Pi 3b Armbian Maintainer? ;-)

@Piotr Kędzia Please try one of the Armbian images from https://www.armbian.com/orangepi3b/

I don't see any images for download from Armbian for the Turing RK1. But the turing-rk1 board definition exists. Your best bet is to compile your own image.

"docker container ls" will show you the right ports.

Another report of this issue. Went away on a second build attempt according to the user @uablrek.

an orangepi5-plus compilation succeeded just fine now, so this error is not deterministic

split off the issue from the original into a separate thread Essentially the problem here is that one of the mirrors is apparently redirecting from https to http. This has been a problem in the past and was supposedly fixed, in fact more than once. Obviously, it's never been fixed properly for all cases or there was a regression.

You fail to mention which OS and which release you are running. https://packages.ubuntu.com/noble-updates/torbrowser-launcher is not working for you? Frankly, I don't find 5 and a half hours of compilation time unbearable, but you could also look into using a Launchpad PPA to offload the compilation effort.

merged

I can confirm: https://paste.armbian.de/oxupahozud

Not sure if the target board makes a difference. But FWIW, my compilations for rockpi-4b and orangepi5-plus exhibited the issue while the one for bananapim2plus did not.

You are already discussing this elsewhere. Please don't post several times about the same issue.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Pointing out that you are not even willing to put your own words into a search engine is "condescending"? That takes 5 seconds or less when you claim to have put months and months into it. You are expecting others to do the work for you. I find that quite presumptuous. And no, we do not know there is a bug in Armbian. You haven't done enough research to know enough to claim this for certain. I will put the chances of that being the case at fity-fifty at best. You also have presented no logs whatsoever (even after being asked) to even give others the moderate chance to do this work for you (for free). If you came here to vent, OK, you have now vented. If you came here for a solution, then sorry to say, but you are not even doing the very minimum to get that done.

resolution: https://github.com/armbian/build/issues/8400#issuecomment-3136454158

Thank you for following up. I just did build on bare metal and checked on the result a few minutes ago and came here now to see you already responded. I can confirm this is not a github issue as I ran into the exact same problem on my Thinkpad 16GB RAM and 16GB swap. Never had an OOM issue with any armbian builds before. Thank you for bringing this to our attention.

still looks like a cert error to me ("handshake failed"). but maybe somebody else can see something else.

"doesn't work" or equivalents are not enough information. pastebin your logs somewhere so that people can actually see what exactly doesn't work.

The error message looks pretty straight-forward to me. I suggest you have a look at your certs. Sounds like a generic issue not related to Armbian in any way whatsoever.

Hello @sans-ltd, thank you for providing the logs. 32GB sounds like it should be plenty to compile the image successfully. Have you ever tried to reproduce this on bare metal? Would adding swap space to the github runner to mask the issue be an option? Does the runner always error out at the same step? It's a bit odd for apt to be running out of memory like this. Have you been able to monitor memory consumption during a failed build? Can you share your github workflow definition?

As far as I understand the terminology, "standard support" means we have someone in the core team who has access to the device and regularly runs boot tests on the actual hardware and is willing to attempt to fix issues that are found (best effort, not a guarantee). It does not mean all hardware features of the board are working. Source