tabrisnet

Ok, looks like I just missed the special instructions about the recovery button. ☹️

https://paste.armbian.com/qocicuyote.yaml <-- captured from debug UART Brand new odroid-m1, Samsung Pro Endurance 256GB; and a brand-new/uninitialized Samsung PM9A1 256GB NVMe. It drops me to a shell [presumably the initramfs]. Note: I'm not out of options yet, I can try building my own image with newer current or edge kernels. Edited to add: I think it's booting me to the petitboot env, not even attempting to boot the SD card,

Well, the source code is still on github so you could try building it. I can't find that tag in `armbian/build`, but did find `v24.11.0-trunk.303` It does build [I guessed at jammy, maybe it should be noble] time ./compile.sh build BOARD=jetson-nano BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes RELEASE=jammy KERNEL_CONFIGURE=no KERNEL_GIT=full ARTIFACT_IGNORE_CACHE=yes [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img (4.07GiB) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.sha (202.00B) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.txt (19.29KiB) ]

this board appears to have effervesced from your repo in this commit, just a few weeks ago. is it maintained elsewhere?

does anybody have a photo of the actual chip? A3A444 isn't finding much useful in google for a datasheet

@superkali: "defective" or "silicon lottery loser" ??

can we have HS200 be the default but an armbian-config option to enable HS400 via an overlay [with appropriate warnings/documentation]? fwiw I have a NanoPC-T6 with current/mainline kernel [running my HomeAssistant, so I'm loathe to mess with it] that I had to abandon using the eMMC due to IO errors. It's in the official case so can't do much inspection either.

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.

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,

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.

https://github.com/armbian/build/pull/8517 appears to fix my SFP problems.