laibsch

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

As @Werner said and then just ask any specific questions you may have. Welcome to the Armbian community, @Sahil Usmani.

Seriously? https://www.lmgt.org/?q=simulate+high+latency https://duckduckgo.com/?q=simulate+high+latency You're welcome. "Many many months" of what?

You are asking for help. Have you actually followed the guidance you were given, though? Have you been successful to compile an image for any target (virtual or otherwise)?

@Sandeep Please don't hijack / necro old threads. You have a completely different issue from the OP, this particular one was already solved. Please open a new thread and show the output of "cat /etc/apt/sources.list /etc/apt/sources.list.d/*.{list,sources}". Feel free to ping me there and I'll be happy to help.

OK, what does that leave us with? You tried an armbian image with armbian and debian kernel and binaries and get a kernel oops. Then you tried an Armbian image with Armbian kernel and Debian userland but a self-compiled labwc and you do not get the crash? Summary so far correct?

I cannot provide the answer, but have you had a chance to check https://www.armbian.com/tinkerboard/ ? I am not sure if the maintainer Paolo is active in the forum. Edit: found him. ping @jock

The answer to your question is "sudo run-parts /etc/update-motd.d/", @snow To have that information displayed every time you login, you might want to check ~/.profile or ~/.bash* files if you use bash as your shell. I am not sure what problem you might run into since as you can see above the run-parts command needs root. Do some testing, with and without root.

I'm willing to help guide @Error1429 a bit on how to get this done.

@7alken I am using incus these days for managing VMs, not virtualbox anymore. Haven't tested it with these images, yet. You can use qemu directly as well, but incus simplifies this kind of stuff a lot.

I am using dnsmasq for that purpose

Have you reached out to 1password?

You forgot to mention a very important caveat, in that all filesystems on that device sda should be unmounted when you dd (BTW, pv is cooler than dd for this). That means, you have to boot off a different device. "sudo dd bs=4M if=/dev/sda | xz -v armbian_odroidc4_11_01_2025.img.xz" gets you the desired compression in one go. | is called a pipe.

so, you are good now?

Hello and thank you for your problem report. You are absolutely spot on, no worries! Your board is community maintained status. I would advise you to try and contact Chris, the listed maintainer of this board and see if you guys can pinpoint the root cause of the problem and provide a fix we can incorporate via a PR.

not sure, but sounds like a boot order issue? @meco, I believe you are the maintainer for this board, aren't you?

Are you twwn on github, @tast ky? As mentioned in the bug tracker, you need to try a different image. Please keep the discussion of run-time issues in the forum. This is where run-time bug triage happens. Until the time one can essentially make a PR with a clear code fix, the forum is where we discuss run-time problems.

I'd say try flashing again with a different image, possibly one that worked in one of your other boards. Verify the download and the flash process with checksums.

Yes, your list of questions is a bit long (understatement) and as such comes off demanding. I would say armbian or an SBC is not for you if you require a great amount of handholding and that's the vibe I am getting from your laundry list of questions for everything under the sun. I guess you want to be thorough before taking the plunge, but you need to take armbian with a different attitude, I guess; be happy when it runs, get down to help fixing it when it doesn't. We are NOT selling you a product.