laibsch

Thank you for your report, @DanflashX So, your audio is working out of the box and the change in https://github.com/armbian/build/pull/8568 is not necessary for the Opi 5 Pro?

Anybody here with the Opi 5 Pro? Does it need the same change? https://github.com/armbian/build/pull/8568

not everything is mounted, at least not in the way you expect it. check "swapon -s"

I don't think I can condone changing a very, very security-relevant part of your setup without fully understanding its implications. So, it's good you ask here. I can't answer it off the top of my hat, but maybe somebody else can chime in. I don't think I would bother for the sake of 5 seconds. Are you logging in and out all the time? By the way, PAM is short for pluggable authentication module, so you are disabling an authentication mechanism.

I agree that would normally be a bug. And Debian would agree and in turn us. We have not established that being the case yet, though. At least not for me since @bushw has not yet responded. @Cancer Do you have an example for me to look into? Please do tell us more.

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!