All Activity

@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)

He meant this forum-post was moved to "staging". Maybe someone in the community will be able to help. (I can't help much with your problem, only explain what he meant with the post) Try what yourself suggested, run fsck from another system and see. But if a filesystem becomes readonly, it can mean that the drive is starting to fail physically.

I understand that you're overworked and underpaid. This is free software, so I won't demand more labor from any of you. That said, I think it would build trust to at least have a little temporary pop-up (not the right word but I dont know what it's called) on the homepage that says something like "Current kernels may be vulnerable to this bug, we're working to resolve this, here are some relevant links" and then post the kernel dot org patch for this bug and point people to the Armbian build system. Surely the amount of effort it would take to do that is equal to or even less than it took to give me such a thorough response (which I appreciate btw).

Thanks @bschnei! It built successfully. -- Success: NTIM Processing has completed successfully! Finish time: 05/05/26 20:14:07 TBB Exiting...! No input file for TIMN is supplied Total number of images to process in file[0] - 3 0 Image at offset 00000000 is TIM_ATF.bin 1 Image at offset 00004000 is wtmi.bin 2 Image at offset 00015000 is boot-image.bin Total number of images 3 Built ebu-bootloader/trusted-firmware-a/build/a3700/release/flash-image.bin successfully

I have been using Proton 11 Arm64 for weeks. It has good compatibilities in general (some games I have tested still broke). However, I prefer Proton 11 (Box64), it gives better performance.

We understand the concern, and we appreciate the effort put into testing and documenting the issue. At the same time, it is important to understand the realities of the embedded Linux ecosystem. Armbian supports a very large combination of SoCs, vendor kernels, boot chains, and downstream modifications across several hundred boards. Security response and validation in this environment is significantly more complex than in standardized desktop/server distributions. Explained here: https://github.com/armbian/build/issues/6937#issuecomment-4366571379 This is not a matter of ignoring the issue, but of limited engineering resources, kernel fragmentation, and the high cost of validating fixes safely across multiple platforms. Project can only finance security from your contributions https://github.com/sponsors/armbian volonteers or sponsors. Until none is taking this seriously, there is little what existing team members can do. We already attempted mitigation work on one of the most widely used kernel branches: https://github.com/armbian/linux-rockchip/pull/475 but even targeted fixes require substantial testing effort and may (i am sure it will) introduce regressions on affected hardware families. Current resources barely sustain even our regular release and maintenance process: https://docs.armbian.com/Process_Release-Model/ For users who need receiving upstream fixes faster and are willing to accept a higher risk of regressions on hardware feature breakage, there is always an option to switch to rolling/daily builds, where fix may already be available: https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling Tradeoff between stability, validation cost, hardware compatibility, and update speed is unfortunately a sad reality of embedded Linux maintenance.

@jock It looks like a known bug in the rk35xx u-boot code fixed by luckfox-lyra-ultra-yocto

Steps to repeat the bug: 1) use the cross platform PoC written in C, the Python one that everyone is sharing contains obfuscated code (bad ju-ju) and is x86_64 specific `git clone https://github.com/tgies/copy-fail-c` `cd copy-fail-c` 2) compile either on your target device natively, or do what I did and cross-compile it as a static binary using an aarch64-linux-musl toolchain (this made it easy to test on different SBCs) `PREFIX="/opt/toolchains/aarch64-linux-musl-cross" CC=aarch64-linux-musl-gcc LD=aarch64-linux-musl-ld CFLAGS="-static -fPIC -I/opt/toolchains/aarch64-linux-musl-cross/include -L/opt/toolchains/aarch64-linux-musl-cross/lib" LDFLAGS="-static -fPIE -L/opt/toolchains/aarch64-linux-musl-cross/lib" make -j$(nproc --all)` 3) pass the resulting binaries "payload" and "exploit" to your target device (if you cross compiled) 4) from an unprivileged user account not in the sudo group, run the exploit I'm not here to point fingers but I would like to see AT LEAST an advisory of this potentially devastating bug with a public exploit available on the Armbian homepage, radio silence for over a week seems completely inappropriate to me

@meco awesome - I see it's merged. how long does it take for a new image to be built?

I hear that now we have proton 11 with arm64 support. Does anyone try to test games with that new version??

Sorry I don't understand.

Background - I have a Helios64 NAS with 4 x HDDs running Armbian 25.11.2 with kernel 6.12.58. The HDDs each have a ZFS partition but the partitions aren't imported. The OS is running from an sd card and logging is to ram. Power management and spin-down on the HDDs is disabled. Despite all this *something* is causing the heads to move every second or two. iotop shows no disk activity . lsof +d /mnt/sda etc. shows no open files and fatrace shows files in /usr and /var but nothing on /dev/sda etc. So, whilst it doesn't look as if any files are being accessed the HDDs are still doing something. The question is WHAT and how do I stop it ? Any ideas ?

Another interesting thing is that snd_usb_audio is not loaded as a module and seems to be compiled. I tried in /boot/armbianEnv.tx in extrargs= put snd_usb_audio.index=0 but that didn't work either, unless a different name should be provided instead of snd_usb_audio.

By the way, it's a shame the old method of forcing the bit card number via /etc/modprobe.d/alsa.conf didn't work on Armbian. options snd_usb_audio index=0 options sun4i_codec index=1 options snd_hdmi_audio index=2 alias snd-card-0 snd_usb_audio alias snd-card-1 sun4i_codec alias snd-card-2 snd_hdmi_audio That's why I was looking for a way to disable these additional audio codecs and HDMI, but maybe it's because snd_usb_audio, etc., aren't loaded as modules in the new kerne

Ok I check via ls /proc/device-tree/__symbols__/ addr_mgt hdmi_con_in name r_i2c_pins tcon_tv0 ahub1_codec hdmi_in nmi_intc rmii_pins tcon_tv0_in ahub1_cpu hdmi_in_tcon_top ohci0 r_pio tcon_tv0_in_tcon_top_mixer0 ahub1_mach hdmi_out ohci1 r_rsb tcon_tv0_in_tcon_top_mixer1 ahub1_plat hdmi_out_con ohci2 r_rsb_pins tcon_tv0_out ahub_dam_mach hdmi_phy ohci3 rtc tcon_tv0_out_tcon_top ahub_dam_plat i2c0 osc24M sid ths axp313 i2c0_pins pio spdif ths_calibration ccu i2c1 planes spdif_tx_pin uart0 codec i2c1_pi_pins prcm_ppu spi0 uart0_ph_pins cpu0 i2c2 pwm spi0_cs0_pin uart1 cpu1 i2c2_ph_pins pwm0 spi0_pins uart1_pins cpu2 i2c2_pi_pins pwm0_pin spi1 uart1_rts_cts_pins cpu3 i2c3 pwm1 spi1_cs0_pin uart2 cpu_critical i2c3_pa_pins pwm1_pg_pin spi1_cs1_pin uart2_pg_pins cpu_opp_table i2c3_pg_pins pwm1_ph_pin spi1_pins uart2_pg_rts_cts_pins cpu_speed_grade i2c3_ph_pins pwm1_pi_pin sram_c uart2_ph_pins cpu_target i2c4 pwm2 sram_c1 uart2_ph_rts_cts_pins cpu_threshold i2c4_pg_pins pwm2_ph_pin syscon uart2_pi_pins crypto i2c4_ph_pins pwm2_pi_pin tcon_lcd0 uart2_pi_rts_cts_pins ddr_temp_critical iommu pwm3 tcon_lcd0_in uart3 de ir pwm3_ph_pin tcon_lcd0_in_tcon_top_mixer0 uart3_pi_pins de3_sram ir_rx_pin pwm3_pi_pin tcon_lcd0_in_tcon_top_mixer1 uart3_pi_rts_cts_pins display_clocks l2_cache pwm4 tcon_lcd0_out uart4 dma lradc pwm4_ph_pin tcon_top uart4_pi_pins dump_reg mdio0 pwm4_pi_pin tcon_top_hdmi_in uart4_pi_rts_cts_pins ehci0 mdio1 pwm5 tcon_top_hdmi_in_tcon_tv0 uart5 ehci1 mixer0 pwm5_pin tcon_top_hdmi_out uart5_pins ehci2 mixer0_out r_ccu tcon_top_hdmi_out_hdmi usbotg ehci3 mixer0_out_tcon_top_mixer0 reg_aldo1 tcon_top_mixer0_in usbphy emac0 mixer1 reg_dcdc1 tcon_top_mixer0_in_mixer0 ve_sram emac1 mixer1_out reg_dcdc2 tcon_top_mixer0_out ve_temp_critical ext_rgmii_phy mixer1_out_tcon_top_mixer1 reg_dcdc3 tcon_top_mixer0_out_tcon_lcd0 watchdog ext_rgmii_pins mmc0 reg_dldo1 tcon_top_mixer0_out_tcon_tv0 wifi_pwrseq gic mmc0_pins reg_usb1_vbus tcon_top_mixer1_in x32clk_fanout_pin gpadc mmc1 reg_vcc33_wifi tcon_top_mixer1_in_mixer1 gpu mmc1_pins reg_vcc5v tcon_top_mixer1_out gpu_temp_critical mmc2 reg_vcc_wifi_io tcon_top_mixer1_out_tcon_lcd0 hdmi mmc2_pins r_i2c tcon_top_mixer1_out_tcon_tv0 After decompiling the DTS image (H618): grep -A 15 "codec {" /tmp/extracted_tree.dts soundcard-mach,codec { }; }; ahub1_plat { #sound-dai-cells = <0x00>; compatible = "allwinner,sunxi-snd-plat-ahub"; apb_num = <0x01>; dmas = <0x25 0x04 0x25 0x04>; dma-names = "tx\0rx"; playback_cma = <0x80>; capture_cma = <0x80>; tx_fifo_size = <0x80>; rx_fifo_size = <0x80>; tdm_num = <0x01>; tx_pin = <0x00>; -- soundcard-mach,codec { sound-dai = <0x33>; phandle = <0x98>; }; }; usb@5100000 { compatible = "allwinner,sun50i-h616-musb\0allwinner,sun8i-h3-musb"; reg = <0x5100000 0x400>; clocks = <0x02 0x70>; resets = <0x02 0x32>; interrupts = <0x00 0x19 0x04>; interrupt-names = "mc"; phys = <0x34 0x00>; phy-names = "usb"; extcon = <0x34 0x00>; root@host:/tmp# grep -A 15 "hdmi_sound {" /tmp/extracted_tree.dts root@host:/tmp# grep -A 10 "ahub1_mach {" /tmp/extracted_tree.dts ahub1_mach { compatible = "allwinner,sunxi-snd-mach"; soundcard-mach,name = "HDMI"; soundcard-mach,format = "i2s"; soundcard-mach,frame-master = <0x31>; soundcard-mach,bitclock-master = <0x31>; soundcard-mach,slot-num = <0x02>; soundcard-mach,slot-width = <0x20>; status = "okay"; phandle = <0x97>; HDMI Audio is located under the label: ahub1_mach Analog Codec is associated with: ahub1_plat and codec These nodes have a default status of "okay," which causes them to occupy slots 0 and 1. and use /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target = <&codec>; __overlay__ { status = "disabled"; }; }; fragment@1 { target = <&ahub1_codec>; __overlay__ { status = "disabled"; }; }; fragment@2 { target = <&hdmi>; __overlay__ { status = "disabled"; }; }; fragment@3 { target = <&spdif>; __overlay__ { status = "disabled"; }; }; fragment@4 { target = <&ahub1_mach>; __overlay__ { status = "disabled"; }; }; }; and after reboot not show HDMI and Codec audio and USB sound card has 0 number

Well, with the new image there was some progress, but I will give up for now. I will look for an SD card and try again using it. I’m confident that I will finally succeed in this operation.

I don't know the names either. I suggest to look at the original device tree by decompiling it: dtc -I dtb -O dts /boot/dtb/allwinner/whateverthenameofthezero3devicetreewas.dtb

@Maberikku Great! @humanus Nick said you hit a kernel error on 6.6. Can you paste the details here.