All Activity

Hey guys, So I wanted to update the OS on my NAS to patch the Copy Fail vulnerability today. I installed everything, I also did an apt-upgrade (not a full one) to make sure my kernel was as up to date as I could get it, and I also updated the initramfs, too. Now when I boot up the Kobol, I can hear the disks spinning up after a few seconds upon powering up, they make an odd noise and then just stop. The LEDs on the front panel also no longer show blue anymore, and `fdisk -l` no longer shows anything. I know for a fact these HDDs are not dead. They have worked perfectly fine before the upgrade, and the SATA pins look perfectly clean. I even tried swapping from bays 1 and 2 to 3 and 4 and still no dice. I may go through and attach serial or dmesg output. But yeah, nothing much about "ata" shows up in `dmesg` after booting.

(I am not part of Armbian other than the community, and have donated money, so I feel no obligation to be "professional") Ok, if you want to act like a clown, I'll treat you like a clown: Don't click unknown links, don't download unknown scripts or applications and you are fine. You know, use common sense. I'm sorry you feel "wronged" by this free and open source project because it doesn't focus the tiny amount of assets they have to manually remove something that pretty much is a nothing burger (and will be solved in the next update), unless you make yourself vulnerable by infecting yourself with with an RCE malware/virus or give physical access to people you can't trust. If you think making a text on their website would "protect" people, when this exploit has been mentioned by more or less every single linux outlet in existence, I don't know what to say. You are not doing this to "protect others", you do it for ego reasons. (Sorry mods, I won't respond more with the risk of starting a war, but if being mentioned in the way op did, I WILL defend myself.) Also, a link about Dirty Frag: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html Mitigation:

For those who want to follow the linux-sunxi mailing list but not as plain emails but in patchwork format, feel free to use https://patchwork.armbian.eu/project/patchwork/list/

Multiple options: - wait for upcoming 26.05 release which will most likely have an updated kernel package including a fix for this - as suggested use nightly - use the build framework to build an most up-to-date kernel package set by yourself (its very easy) which then can be installed via dpkg -i However since "dirty frag" just showed up, there is more to fix anyway... Edit: looks like fix for dirty frag hit upstream earlier today

you chould check the device tree which mode is there by default. I assume it is not "host" but something else. I believe the device tree follows upstream and is not altered by Armbian. Not sure though, needs research

You posted in the wrong sub-forum. Your topic is about the orangepizero2w which for once has nothing to do with orangepizero2 and for the other is unsupported by Armbian. Therefore the topic was moved (and the tag adjusted) to the unsupported/community supported section of the forums, also known as staging. Latter do not offer dedicated sub-forums for each individual board.

to be able to help you, I need you to run: sudo armbianmonitor -u This collects system logs, including the last 250 lines of dmesg, and provides a URL to a pasteboard for easy sharing with the community for help.

Hey TRay, If your main goal is just to make sure the USB sound card is always recognized as Card 0, you don't necessarily have to completely disable the other devices. You can just force ALSA to prioritize the USB card. Try creating or editing a configuration file in modprobe. Run sudo nano /etc/modprobe.d/alsa-base.conf and add this line: options snd-usb-audio index=0 Reboot, and your USB card should grab the 0 slot. If you really want to completely disable the onboard HDMI and Codec audio, your best bet is to look in armbian-config under System -> Hardware and toggle off the overlays for analog audio and HDMI audio, or you can blacklist the specific kernel modules (like sun4i-codec) in /etc/modprobe.d/blacklist.conf. Hope this helps get your setup working!

@SymbiosisSystems To get those changes into the mainline build is currently not the solution preferred by the maintainer of this board, because it is some kind of a hot fix. To boot your helios64 to the command line you could try an image from the archive and boot from sd. A system on emmc could then be manipulated using chroot.

@BipBip1981 the dtb posted for the 6.18 kernel is different to the dtb posted for the 6.6 kernel though so where can I find the dtb built for the 6.12 kernel that Prahal shared with you rk3399-kobol-helios64.dtb-6.XX.xx-L2-hs400-opp ?

But one reason I did not understand is that I can not find any topic "staging" ?

Ultimately if the only way to get the Helios64 to boot is to integrate the dtb changes do I need to be building my own image with the changes integrated (rather than copying them into a pre-built image) . @ebin-dev what would be required to get these dtb patches into the mainline build ?

@BipBip1981 that is the challenge though - getting it to boot to the shell ! Copying the dtb onto the sd card isn't enough , you need to then rebuild the fs image and how do you do this if you can't boot from the image ?!

@BipBip1981 the challenge is being able to get it to boot to the shell so that I can update the dtb though (unless there is another way) !

@jamesharton can you send pictures of your board with the memory module print visible?

Hi I managed to fix an issue with the usb-c port of the orange pi 5 plus. It seems the device is not activated unless you put it in host mode yourself: as user root: echo host >/sys/kernel/debug/usb/fc000000.usb/mode I have tried a usb-c network card and usb stick. Both work after this command! I noticed this when I installed the 6.1.115-vendor-rk35xx kernel. This one does not need this setting, it switches automatically from device mode to host and vice versa. I had alot of problems with analog sound on older kernels, e.g. youtube just hangs unless you mute the sound. But sound in noble 6.19.0-edge-rockchip64 works now, I switched to pipewire however. Thanks to the maintainers of Armbian and OrangePi for this awesomeness!

You know there is a fruit company in Cambridge UK that is proud to tell they have sold 75 million pieces and 75% is to non-noobs. They provide passwordless sudo by default and a self-modifying rpi-update script by default in their OS. So why so complicated with this copy-fail exploit, every script kiddy had and has an easy task of keeping the noobs on a leash for more than a decade.

@qq20739111 No, this was on 6.18. I already purged this image and the dtbs were updated since then, but the boot log is here: https://paste.armbian.eu/ewudaciluc.pl

There has been several improvements that hasn't landed to stable images yet - try rolling releases for this board.

On it. Coming soon.

I discovered that the problem is uboot related. It started after updating to the last stable armbian version. When the helios fail to boot I can attacche the usb cable and type boot on the uboot prompt and it start to work. If i power off and power on with cable attacched (to debug the error) it boot without issue! Very strange! Which version of uboot is the recommended one?

If someone wants, Orange Pi 1.0.8 - Ubuntu Jammy with Linux 6.6.98-sun60iw2 https://drive.google.com/drive/folders/1ozZLvQDknaz2xC5lXtg7UhGfhotXRR_2 GPU isn't working.

@Igor can you replace 5B-Plus and 5T images with new ones from CI? On the very latest they will be available with the 26.05 release by the end of the month.

Really disappointing that both responses to the original post (although the first was at least polite) are basically "f*ck you, pay me" 🙄 I've already mitigated this on my own devices, my concern is for other users of this distribution. And yeah, LPE isn't RCE, but it still deserves an advisory. Consider how easy it would be for an attacker to embed this exploit in a malicious file download + god knows what kind of payload and turn your computer into a zombie in a botnet, a cryptominer, hit you with ransomware, etc. When mentioning a real security issue gets a response this crappy, it doesn't bode well for the future of the project. Igor was at least professional. But go ahead, Bedna, tell me more about why the homepage being updated to include an advisory costs money that I should be sending instead of making bug reports 🙄 pathetic

This, even though serious, it's "only" a privilege escalation, not remote code execution (RCE), so if someone were to use this on you, they would first need to have physical access OR access remotely (RCE) to be able to run the exploit and escalate to root. And if you have a malware with RCE, you are already f**ed. In time, I'm pretty sure upstream patches will spread down to armbian builds too. In the meantime if you think someone might be able to get access and escalate, you can disable algif_aead (or try to apply patches yourself) as mentioned in https://xint.io/blog/copy-fail-linux-distributions Another solution is for you to pay a developer to do changes/testing needed If you don't "demand more labor", then why are you requesting more labor? (don't answer, it's a rhetorical question)