laibsch

kudos for your perseverance. and thank you for sharing your findings. I hope you will be able to work it out eventually.

Is your rootfs formatted ext4? By bricked you mean, boot would be interrupted, but the brick situation is easily fixable for a skilled technician by doing an fsck?

Keep up the fight, good luck!

I am glad to hear of your success Beware that edge is the bleeding edge and where we break things. Vendor is the one the board maker supplied you with, most likely outdated and hacked up. You are usually best off with the current kernel, except of course when there was some recent hardware enablement work going on in the edge kernel for your work.

'for kernel in current edge vendor;do ./compile.sh BOARD=orangepi5pro BUILD_DESKTOP="no" BRANCH=$kernel RELEASE=noble KERNEL_CONFIGURE=no BUILD_MINIMAL=yes SHARE_LOG=yes;done' should do it, for example. That would get you an image with an Armbian-patched kernel of the current, edge and vendor flavor. It's really THAT simple :-D

follow http://debug.armbian.de

might be hard to find such an old image even from the archive why not one of the newer ones? https://www.armbian.com/cubox-i/

How would one do that exactly?

https://linux-sunxi.org/Tanix_TX1 Piotr's github is easy enough to google for those who need it.

PR in this context is a "pull request" on github, you are telling us to pull some updates from your github code base

unfortunately, we do not have a maintainer for this board, so it gets very little testing

it should be "rock-4se". did you enable the display of the community supported boards? the compile tool will only display those with standard support by default. to speed things up, you can simply add 'BOARD="rock-4se"' to ./compile.sh

Certainly better moving forward and possibly less work, too. Good luck.

that may be a hard task, so let's get into the obvious question first: Why do you need such an old kernel? I understand it's LTS, but the question is still why it has to be this kernel and not another.

Is this not done by default, yet? Even on the latest images? @twwn Would you be kind enough to test / comment as well?

Never too late to express gratitude and say "Thank you for sharing your findings"

Apologies for the late reply. That error sounds like running out of space on the filesystem (maybe the tmpfs portions?), not running out of RAM, that would give you a different error.

@c0rnelius is the maintainer of the board. Maybe he has something to say.

Armbian's archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux. Images shall only be written with imaging tools that validate burning results. This saves you from corrupted SD card contents. Approved Tools: USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool (may contain spyware) Did the validation of you burning the image succeed?

Thank you for letting us know and polish up our next release. I'm sure @Igor will have a look shortly.

sorry to hear about your troubles The Tritium H5 is maintained by https://github.com/Tonymac32. Not sure if he is active here in the forum.

All I can say about the topic is to give you this link: https://wiki.kobol.io/helios64/pwm/

look into understanding what armbian-config does behind the scenes and replicate that. I think that is a better option anyhow. armbian-config is known to royally screw up your system every now and then.

aww, too bad. I kinda like the tea distribution. ;-) regardless, I still can't find a reference as to what it really is.

was it kernel 6.16?