All Activity

maybe not a strictly a systemd bug... but a netplan stupidity. root@ratatosk:~# ethtool --show-permaddr eth1 Permanent address: not set https://github.com/systemd/systemd/pull/14448/files <-- PR that created this systemd match feature

Latest armbian update 25.11 trunk 45 also breaks boot...

Thx for your reply. Yes i tried both together. And just one. No difference. # Enable DRM VC4 V3D driver dtoverlay=vc4-kms-v3d # Enable the Touch Display 2 DSI panel dtoverlay=vc4-kms-dsi-ili9881-7inch

making a copy of the file from /run/, changing the YAML to use MAC, then diff root@ratatosk:~# netplan generate root@ratatosk:~# diff -purN /run/systemd/network/10-netplan-eth1.network /root/netplan-eth1-namematch.network --- /run/systemd/network/10-netplan-eth1.network 2025-08-19 20:10:54.900000038 +0000 +++ /root/netplan-eth1-namematch.network 2025-08-19 20:10:36.980000037 +0000 @@ -1,5 +1,5 @@ [Match] -PermanentMACAddress=6a:c9:72:53:13:d5 +Name=eth1 [Network] EmitLLDP=true feels like a systemD bug ☹️

@Piotr sTry this image https://github.com/NickAlilovic/build/releases/download/20250306/Armbian-unofficial_25.05.0-trunk_X96q-lpddr3_bookworm_edge_6.12.11_xfce_desktop.img.xz to fix Ethernet you need to edit this file https://github.com/NickAlilovic/build/blob/v20250306/patch/u-boot/u-boot-h616/159-add-x96-q-lpddr3-v1.3-defconfig.patch. Change 16 to 0. Then compile a new image. +&mdio1 { + rmii_phy: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; +}; more information can be found here

Ok, so using the match name *does* work, still makes no sense. root@ratatosk:~# head /etc/netplan/20-ethLAN.yaml network: version: 2 renderer: networkd ethernets: eth1: match: #macaddress: '6a:c9:72:53:13:d5' name: eth1 #set-name: ethLAN addresses: [ "192.168.88.253/23" ] root@ratatosk:~# networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded unmanaged 3 eth1 ether routable configured 4 eth2 ether off unmanaged 5 wan dsa off unmanaged 6 lan1 dsa routable configured 7 lan2 dsa off unmanaged 8 lan3 dsa off unmanaged 8 links listed.

The eth0/lan1 MAC does change... the eth1/eth2 MACs do not change. I've checked over multiple reboot cycles. 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 6a:c9:72:53:13:d5 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 32:b0:1b:6f:4e:e9 brd ff:ff:ff:ff:ff:ff root@ratatosk:~# uptime 20:05:19 up 5 min, 1 user, load average: 0.13, 0.39, 0.21 just rebooted, the MACs are stable 🐴 I could try reconfiguring the netplan config to use the name [like with lan1] instead of MAC... but that will of course mean I can't rename.

Weird. Check logs and verify matching - mac - if not changing random - is usually safest way. I haven't played under network manger lately ... perhaps there lies the problem or network devices gets up with a delay. I will try to recreate during week.

rules in /etc/udev/rules.d did *nothing*. tried with 00 prefix and 99 prefix. udevadm test-builtin net_setup_link didn't mention the filepath either. But I could make it do stuff with /etc/systemd/network/foo.link, which is what's current[ly not deleted yet from previous attempts]. Which makes it even weirder that it still won't rename at boot. Note that the problem is a lot less the renaming and more that networkd refuses to manage the interfaces, even if I give up on renaming,

OS is stable, errors you are experiencing are likely related to faulty HW component as @eselarm already exposed. And we would most likely notice such anomaly before it gets to you. There are thousands of users and this is the only report of this kind ... Boards are going to the market at high rate, while users support remains more or less the same in past 10 years https://docs.armbian.com/User-Guide_Board-Support-Rules/ Community builds and their upgrades are untested as size of Armbian can only cope with a small selection of boards we call as "standard support", where we have volunteers behind. Community builds are on Debian / Arch images level, but packed with more features. https://github.com/armbian/community?tab=readme-ov-file#purpose-of-this-repository For those - Armbian provides build and hosting infrastructure, place to meet - this forum - while everything else is anyone's problem.

Did you try renaming by using udev rule? Example: sudo nano /etc/udev/rules.d/76-rename-wifi-by-mac.rules SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="b8:2d:28:5a:55:92", NAME="wlxb82d285a5592" and then proceed with whatever. Both systemd-networkd and network manager should work.

BPI-R4, but that is probably the least of my problems. setting up netplan, like the docs say I have to. using networkd, or trying... renaming the eth1 interface to ethLAN, keeping lan1 as-is. networkctl always says that eth1 or ethLAN is unmanaged. Note that I'm using the ttyS0 serial console. root@ratatosk:~# networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded unmanaged 3 eth1 ether off unmanaged 4 eth2 ether off unmanaged 5 wan dsa off unmanaged 6 lan1 dsa routable configured 7 lan2 dsa off unmanaged 8 lan3 dsa off unmanaged root@ratatosk:~# netplan apply [ 141.017704] mtk_soc_eth 15100000.ethernet ethLAN: renamed from eth1 [ 141.068835] mtk_soc_eth 15100000.ethernet ethEXT1: renamed from eth2 root@ratatosk:~# networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded unmanaged 3 ethLAN ether off unmanaged 4 ethEXT1 ether off unmanaged 5 wan dsa off unmanaged 6 lan1 dsa routable configured 7 lan2 dsa off unmanaged 8 lan3 dsa off unmanaged Here's my config. Note that it does in fact rename the interfaces... albeit not at boot 😑 root@ratatosk:~# cat /etc/netplan/20-ethLAN.yaml network: version: 2 renderer: networkd ethernets: ethLAN: match: macaddress: '6a:c9:72:53:13:d5' #set-name: ethLAN #tried with and without this addresses: [ "192.168.88.253/23" ] emit-lldp: true dhcp4: false dhcp6: false #ignore-carrier: true nameservers: addresses: - 192.168.82.55 search: - tabris.net routes: #- to: 192.168.88.0/23 # metric: 10 # from: 192.168.88.253 # scope: link # type: local - to: "default" via: "192.168.88.254" root@ratatosk:~# cat /etc/netplan/11-lan1.yaml network: version: 2 renderer: networkd ethernets: lan1: match: name: "lan1" addresses: - "192.168.88.250/23" nameservers: addresses: - 192.168.82.55 search: - tabris.net # routes: # - to: "default" # via: "192.168.88.254" note that lan1 works! ethLAN, whether named eth1 or ethLAN... does not. I tried using renderer: NetworkManager It then tries to restart networkd & stop NetworkManager. but it can eventually work... but I have to sacrifice a rubber chicken [stupid manual steps like manually setting the interfaces up with ip link] each time, and they're starting to pile up. it will *not* work at boot no matter what I do.

Aliexpress item: https://pl.aliexpress.com/item/1005006249858881.html Extracted dtb and dts files attached. It boots Warpme/miniarch image for X96 with LPDDR3 RAM https://github.com/warpme/miniarch/releases/download/f3b14fbae071/MiniArch-20240715-6.16.1-board-h313.x96_q_lpddr3-SD-Image.img.xz However internal Ethernet port is silent. It can work through USB->ETH adapter though. Any Idea on how to make Ethernet working? sun50.dtb sun50.dts

Hi. Did you add / enable required overlays ? https://chatgpt.com/share/68a49507-d420-8005-a687-04d8daf0e93a It looks like kernel support is enabled.

@buzz89

I just got an H618 board. It is able to boot using the Vontar image, but the onboard Ethernet is not working. USB Ethernet works fine. The Ethernet chip is RTL8211F, I’m hoping to get some guidance on this issue. Here’s the relevant dmesg output related to Ethernet: dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 2.422638] dwmac-sun8i 5030000.ethernet: IRQ eth_wake_irq not found [ 2.422669] dwmac-sun8i 5030000.ethernet: IRQ eth_lpi not found [ 2.422678] dwmac-sun8i 5030000.ethernet: IRQ sfty not found [ 2.422989] dwmac-sun8i 5030000.ethernet: supply phy-io not found, using dummy regulator [ 2.423245] dwmac-sun8i 5030000.ethernet: PTP uses main clock [ 2.423316] dwmac-sun8i 5030000.ethernet: Current syscon value is not the default 53fe1 (expect 0) [ 2.426176] dwmac-sun8i 5030000.ethernet: No HW DMA feature register supported [ 2.426204] dwmac-sun8i 5030000.ethernet: RX Checksum Offload Engine supported [ 2.426211] dwmac-sun8i 5030000.ethernet: COE Type 2 [ 2.426220] dwmac-sun8i 5030000.ethernet: TX Checksum insertion supported [ 2.426226] dwmac-sun8i 5030000.ethernet: Normal descriptors [ 2.426232] dwmac-sun8i 5030000.ethernet: Chain mode enabled [ 2.469198] dwmac-sun8i 5030000.ethernet end0: renamed from eth0 [ 3.060680] asix 2-1:1.0 eth0: register 'asix' at usb-5200000.usb-1, ASIX AX88772B USB 2.0 Ethernet, 00:0e:c6:c5:f5:e5 [ 3.068667] asix 2-1:1.0 enx000ec6c5f5e5: renamed from eth0 [ 11.377369] dwmac-sun8i 5030000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 11.388786] dwmac-sun8i 5030000.ethernet end0: PHY [stmmac-0:00] driver [Generic PHY] (irq=POLL) [ 11.388838] dwmac-sun8i 5030000.ethernet end0: No Safety Features support found [ 11.388849] dwmac-sun8i 5030000.ethernet end0: No MAC Management Counters available [ 11.388859] dwmac-sun8i 5030000.ethernet end0: PTP not supported by HW [ 11.393925] dwmac-sun8i 5030000.ethernet end0: configuring for phy/rmii link mode

Collabora is heading to Amsterdam with talks, demos, and workshops covering Embedded Linux, KernelCI, Bluetooth & Auracast, mainline video capture for Rockchip, and more. Join us to see our latest open source work in action! View the full article

@prahal - I tried a number of those images but none worked. With RoobiOS I see that all of the blue lights below the SATA ports (i.e. on the underside of the board) light up as blue for a couple of seconds, then they turn off and then they flash twice ... the screen comes on and after a couple of error messages the Installation GUI starts. With the images from the links you provided, I don't get the blue lights (although I do get a yellow network link light). However ... in RoobiOS I'm given the option of various images to install ... including the option for "custom" - I've selected that and entered https://fi.mirror.armbian.de/incoming/prahal/rock-5-itx/archive/Armbian_25.8.1_Rock-5-itx_bookworm_current_6.12.41_minimal.img.xz This gives a circle (of death?!) and "Loading ..." in RoobiOS but I see there's flashing green light on the ethernet port - which suggests that there's activity so maybe it's just a slow download?

Wifi chip model?

... straightforward and smooth.

With linux 6.12 the optimizations in /etc/rc.local do not apply anymore since some configuration options have vanished. So if you like to have a stable 2.5Gbit/s network connection without timeouts, linux-6.6 is still recommended (bookworm and trixie). You can build it yourself using an Armbian snapshot (from Dec. 2024) or download a recent linux-6.6.100 from here.

Hi, i want to try the Gnome on Armbian with my Raspberry Setup. Pi5 with Touchdisplay2. The Display is working but without touch input. I looked through the /boot/firmware/config.txt and everything looks fine. I also tried to run Gnome on Xorg. Has someone a hint for me?

@Nick AHi,I bought another model of TV box (with the same CPU and eMCP chip model, but a different Wi-Fi chip), and it has the same issue. Could you help me figure out how to solve this? Thank you!

Armbian is a stable OS, but we don't know about what SD-card, power-supply etc you use with your Cubitruck and/or NanoPi Neo+2 The decompression error can simply mean corrupt file due to something wrong with HW. Or something could have gone wrong during download of the files that you or the system decompress. Also note you use a kernel from beta repo (25.11.0-trunk.41). I you want better control, create/build an image formatted as Btrfs, not Ext4. Then you can check where it went wrong. I have several NanoPi-NEOs, all use Btrfs. 2 run 24/7, the others not all the time and usually just get sudden power cut, but they start fine next time. I do in-place upgrade them since years. If something would go wrong, typically as the error you show, I go back to a previous Btrfs snapshot or/and backup from NAS. That is simply what you could do / have done. Maybe something went wrong with that sunxi64 kernel build on the Armbian infrastructure side, that can happen every now and then as it is beta. So Also then, protect your devices again such issues. Also please don't post kernel upgrade errors in a topic about LiPo controller chip. OK for now, but annoying

Thank you Nick, that worked! Not sure what the root cause is but will try to compare and see if I can find it. thanks again