tabrisnet

the current filogic kernel has no info [in github] for where it was forked from, and trying to apply incremental patches from kernel.org I found it contains pieces of 6.14 in an ostensibly 6.12 branch. @chainsx might you be able to divulge where you forked it from?

T'is one reason to prefer boards that take 12V power. and yes, barrel-connectors, but I can't think of any recent boards that use 5V and barrel connectors. NanoPi-M4 vs NanoPC-T4, with a WD Blue SN500, the T4 was stable. the M4 was not. yes, the M4 used the official power supply.

so first thought: you likely want a serial console [what @SteeMan said about UART pads]. If I had to take a stab in the dark with a rubber knife, see the 4 copper-lined holes near the SD card. you'll have to guess at the pinout tho. also, I went googling for 6051p s905w, and I found this armbian post. I am concerned that there are multiple posts [in general, not just here] saying that the wifi chip isn't supported. but they're old. this looks vaguely like your board https://github.com/ophub/amlogic-s9xxx-armbian/issues/2635

Googling suggests the need for Armbian to re-issue their signing keys. Note, I don't think this means they have to generate a new one. Just re-sign it. https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel https://github.com/fwupd/fwupd/issues/7124 @Igor

It's worth noting that you don't have to necessarily change anything in the build process. As long as you plan to not insert partitions in the middle, you can: write the image to the card with parted, resize the root partition to whatever you want make a new partition If you want to have more than 4 partitions total, this works best with GPT partition table, but legacy msdos works too with a little more effort `fsck.ext4 -f /dev/foo` where foo is the root partition `resize2fs /dev/foo` after you have the machine booted, you can then mkfs the new partition [you could probably do it in advance of booting the system too] I do this regularly, b/c I typically only partition about 1/2 or 1/4 of the SD card to leave the rest for wear-leveling. Are you trying to do this as a one-off or are you trying to do it for a dozen or more SBCs of the same type?

This solution feels janky [specifically, netplan-runner.service shouldn't be needed] But... it works. netplan-macaddress-watcher.path [Path] PathChanged=/run/systemd/network/ Unit=netplan-macaddress-watcher.service [Unit] Before=systemd-networkd.service #[Install] #WantedBy=systemd-networkd.service netplan-macaddress-watcher.service [Unit] Description=Rewrites /run/systemd/network PermanentMACAddress to MACAddress Before=systemd-networkd.service network-pre.target [Service] Type=oneshot User=root ExecStart=/bin/bash /usr/local/bin/netplan-macaddress-mangler.sh netplan-runner.service - it runs netplan as late as possible... [Unit] Description=Runs netplan right after boot After=multi-user.target [Service] Type=oneshot User=root ExecStart=/usr/sbin/netplan apply [Install] WantedBy=multi-user.target netplan-macaddress-mangler.sh - This will need to be renamed if published/packaged. #!/bin/bash -x # can we use $TRIGGER_PATH ? https://man.archlinux.org/man/systemd.exec.5.en # no, we can't, it only tells us the directory, not which file was changed. #FIXME: can we skip this for initial boot? sleep 5; # coalesce the calls /usr/bin/sed -i -e 's/^PermanentMACAddress/MACAddress/' /run/systemd/network/*netplan*.{link,network} #echo -n "networkd is: " if systemctl is-active systemd-networkd >/dev/null; then networkctl reload fi

above PR is merged

@Igor how often does netplan run? how possible might it be to sneak in a sed -i -e 's/PermanentMACAddress/MACAddress/' /run/systemd/network/* networkctl reload in my bootup sequence? will DHCP [on ethEXT1] or carrier up/down events break this?

https://forum.banana-pi.org/t/bpi-r4-eeprom/17836/13 suggests we should figure out how to give the info to uboot? or it already does generate it for us in one case? I can say I find eth0's local-mac-address in the running device tree, but the other two mac@ entries lack it. root@ratatosk:/boot# dtc /proc/device-tree 2>/dev/null |grep -PA 10 'mac@[0-9] ' mac@2 { phy-mode = "usxgmii"; compatible = "mediatek,eth-mac"; status = "okay"; pcs-handle = <0x3a 0x3b>; managed = "in-band-status"; phys = <0x3c>; reg = <0x02>; openwrt,netdev-name = "sfp-wan"; sfp = <0x3d>; }; -- mac@0 { phy-mode = "internal"; local-mac-address = [22 16 68 60 40 c2]; mac-address = [22 16 68 60 40 c2]; compatible = "mediatek,eth-mac"; status = "okay"; reg = <0x00>; phandle = <0x2c>; fixed-link { full-duplex; -- mac@1 { phy-mode = "usxgmii"; compatible = "mediatek,eth-mac"; status = "okay"; pcs-handle = <0x36 0x37>; managed = "in-band-status"; phys = <0x38>; reg = <0x01>; openwrt,netdev-name = "sfp-lan"; sfp = <0x39>; };

new Ubuntu/netplan bug: https://bugs.launchpad.net/netplan/+bug/2120999

https://github.com/canonical/netplan/pull/278 <-- related netplan PR

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

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 ☹️

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.