laibsch

this is not a vote but a technical discussion, @Cancer. your hostile tone and unfounded accusations of "somebody was using windows too much" are out of place (and simply laughable). consider yourself warned. and if you don't understand the technicalities maybe it's best to keep quiet? and yes, of course bringing up or down a network interface can obviously affect the firewall. and distribution managers are free to do whatever they want with their distribution, it is theirs not yours. entitled much? this is FOSS, you have the code, change it if you don't like it. but otherwise, keep your entitled and ungrateful attitude to yourself. thank you.

Wow, that is awesome and thank you so much for sharing your findings. Let's get this applied in our repo for the benefit of all Armbian users.

well, I'm certainly happy to hear the good news. consider yourself lucky. creating a raid with mdadm should certainly overwrite all your data. Maybe you got lucky, maybe because you recreated it in the exact same way as before. who knows. what counts is that you did not loose everything after all. because that sucks.

please be more specific, what happened exactly? where did you get that statement that netplan or networkmanager are not supposed to touch firewall settings? when you bring a network interface up or down that can obviously affect firewall rules.

you just overwrote all your data. sorry for the bad news.

Could this be a power supply issue? Unfortunately, there is no official maintainer for your board. None of the core devs will be able to verify your issue.

Armbian kernel and BSP Debian/Ubuntu userland

reopening after moving to "Software / Applications / Userspace"

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

Very bad advice. You just made all files under /home/odroid executable. Don't run server software unless you have at least a rudimentary understanding of Linux, especially if accessible from the internet. Better get hosting and not pwned and part of a botnet. This topic is not specific to Armbian and thus more suitable to be discussed elsewhere.

OK, personally I like btrfs and have been using it exclusively for about a decade now, I guess. Reason are manifold, but the one applicable to your case is that it will automatically detect and if possible fix corruption even when mounted. This can help prevent it from mushrooming into a bricked situation. You can also do an online "btrfs scrub" while the system is mounted, akin to the fsck that requires taking the ext4 FS offline. Look into an AB option where you have a (readonly if you like) failsafe boot system somewhere accessible to uboot in addition to your main OS. And if uboot detects main OS boot failure, have it switch over to the failsafe, ssh in to it and fix the FS corruption. How to do that with uboot, I am not sure. @eselarm might know and quite possibly that is the reason he was asking what uboot version you have as it might depend on that. There are also commercial solutions available like qubee, rauc and mender that you might want to look into.

Happy to report that "./compile.sh build BOARD=rock-3c BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm SHARE_LOG=yes" builds fine for me now.

Hello and thank you for sharing your experience. https://github.com/redrathnure is the maintainer of your board. Not sure if he is active here in the forum.

Yes, I am fairly confident you were experiencing one of these two https://github.com/armbian/build/pull/8554 https://github.com/armbian/build/pull/8555

a fix was just merged for Rockchip, update your repo and try again, maybe you are lucky

let me have a closer look after I successfully unsuccessfully compile this

First suggestion: try trixie or noble instead of bookworm

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?