A step-by-step procedure to reproduce the issue using an SD card install:
- I have installed Arch Linux Arm to an SD card as per https://archlinuxarm.org/platforms/armv ... cchiatobin. The ArchLinuxARM-aarch64-latest.tar.gz I used was dated 2023-03-01 02:50, with md5sum bdef3220a954dadacf03f18d18544204.
- My only deviation from https://archlinuxarm.org/platforms/armv ... cchiatobin instructions was that in the SD card's /boot/dtbs/marvell/ directory I have symlinked the armada-8040-mcbin-singleshot.dtb as armada-8040-mcbin.dtb, because I have the Single Shot board version while u-boot assumes/enforces the Double Shot board version. So, my /boot/dtbs/marvell/armada-8040-mcbin* files are as follows:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# ls -l /boot/dtbs/marvell/armada-8040-mcbin*
-rwxr-xr-x 1 root root 49174 Feb 25 21:45 /boot/dtbs/marvell/armada-8040-mcbin-singleshot.dtb
lrwxrwxrwx 1 root root 32 Mar 12 15:01 /boot/dtbs/marvell/armada-8040-mcbin.dtb -> armada-8040-mcbin-singleshot.dtb
-rwxr-xr-x 1 root root 49096 Feb 25 21:45 /boot/dtbs/marvell/armada-8040-mcbin.dtb.BCK
')
- Such an SD card boots fine and brings up the ethernet:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# uname -a
Linux alarm 6.2.1-1-aarch64-ARCH #1 SMP PREEMPT_DYNAMIC Sat Feb 25 15:18:35 MST 2023 aarch64 GNU/Linux
[root@alarm ~]# journalctl -b | grep -i MACCHIATOBin
Mar 12 14:46:30 alarm kernel: Machine model: Marvell 8040 MACCHIATOBin Single-shot
[root@alarm ~]# lsmod | sort
Module Size Used by
armada_thermal 20480 0
authenc 16384 1 crypto_safexcel
cfg80211 434176 0
crypto_safexcel 147456 0
fuse 139264 1
libdes 24576 1 crypto_safexcel
loop 28672 0
marvell 40960 1
mdio_i2c 20480 1 sfp
mvmdio 16384 0
mvpp2 131072 0
phylink 57344 1 mvpp2
rfkill 32768 2 cfg80211
sbsa_gwdt 16384 0
sfp 40960 0
[root@alarm ~]# networkctl status --full --no-pager
* State: routable
Online state: partial
Address: 192.168.1.112 on eth2
fe80::251:82ff:fe11:2202 on eth2
Gateway: 192.168.1.1 on eth2
DNS: 192.168.1.1
Mar 12 15:23:35 alarm systemd-networkd[334]: eth2: found matching network '/etc/systemd/network/eth.network', based on potentially unpredictable interface name.
Mar 12 15:23:35 alarm systemd-networkd[334]: eth0: Link UP
Mar 12 15:23:35 alarm systemd-networkd[334]: eth1: Link UP
Mar 12 15:23:35 alarm systemd-networkd[334]: eth2: Link UP
Mar 12 15:23:35 alarm systemd-networkd[334]: eth3: Link UP
Mar 12 15:23:38 alarm systemd-networkd[334]: eth2: Gained carrier
Mar 12 15:23:38 alarm systemd-networkd[334]: eth2: found matching network '/etc/systemd/network/eth.network', based on potentially unpredictable interface name.
Mar 12 15:23:38 alarm systemd-networkd[334]: eth2: DHCPv4 address 192.168.1.112/24, gateway 192.168.1.1 acquired from 192.168.1.1
Mar 12 15:23:39 alarm systemd-networkd[334]: Could not set hostname: Access denied
Mar 12 15:23:39 alarm systemd-networkd[334]: eth2: Gained IPv6LL
[root@alarm ~]# ping -c 3 google.com
PING google.com (142.250.74.142) 56(84) bytes of data.
64 bytes from arn11s11-in-f14.1e100.net (142.250.74.142): icmp_seq=1 ttl=110 time=58.5 ms
64 bytes from arn11s11-in-f14.1e100.net (142.250.74.142): icmp_seq=2 ttl=110 time=62.1 ms
64 bytes from arn11s11-in-f14.1e100.net (142.250.74.142): icmp_seq=3 ttl=110 time=60.6 ms
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 58.531/60.404/62.131/1.473 ms
')
- I have backed the original initramfs images up before re-generating them:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# ls -l /boot/initramfs-linux*
-rw------- 1 root root 48524263 Mar 1 01:48 /boot/initramfs-linux-fallback.img
-rw------- 1 root root 48524263 Mar 1 01:48 /boot/initramfs-linux-fallback.img.BCK
-rw------- 1 root root 7562728 Mar 1 01:48 /boot/initramfs-linux.img
-rw------- 1 root root 7562728 Mar 1 01:48 /boot/initramfs-linux.img.BCK
')
- Then I have re-created the initramfs images: mkinitcpio -p linux-aarch64.
- The fallback image isn't any different from the one that came with ArchLinuxARM-aarch64-latest.tar.gz, the default image is ~20 kB bigger:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# ls -l /boot/initramfs-linux*
-rw------- 1 root root 48524263 Mar 12 15:32 /boot/initramfs-linux-fallback.img
-rw------- 1 root root 48524263 Mar 1 01:48 /boot/initramfs-linux-fallback.img.BCK
-rw------- 1 root root 7583553 Mar 12 15:31 /boot/initramfs-linux.img
-rw------- 1 root root 7562728 Mar 1 01:48 /boot/initramfs-linux.img.BCK
[root@alarm ~]# md5sum /boot/initramfs-linux*
9b82e0dcd3c946b9827e58be61e7752d /boot/initramfs-linux-fallback.img
9b82e0dcd3c946b9827e58be61e7752d /boot/initramfs-linux-fallback.img.BCK
f2d6b13221f9e422a4d05092bfc64dc3 /boot/initramfs-linux.img
751573499131670a20948ef193f63a68 /boot/initramfs-linux.img.BCK
')
- After reboot with the new initramfs the eth2 has lost its carrier, no network:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# networkctl status --full --no-pager
* State: no-carrier
Online state: offline
Mar 12 15:37:35 alarm systemd-networkd[324]: eth3: Link UP
Mar 12 15:37:35 alarm systemd-networkd[324]: eth2: found matching network '/etc/systemd/network/eth.network', based on potentially unpredictable interface name.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth2: Configuring with /etc/systemd/network/eth.network.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth1: found matching network '/etc/systemd/network/eth.network', based on potentially unpredictable interface name.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth1: Configuring with /etc/systemd/network/eth.network.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth0: found matching network '/etc/systemd/network/eth.network', based on potentially unpredictable interface name.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth0: Configuring with /etc/systemd/network/eth.network.
Mar 12 15:37:35 alarm systemd-networkd[324]: eth2: Link UP
Mar 12 15:37:35 alarm systemd-networkd[324]: eth1: Link UP
Mar 12 15:37:35 alarm systemd-networkd[324]: eth0: Link UP
')
- Mostly the same set of modules is loaded as with the /boot/initramfs-linux.img that came with ArchLinuxARM-aarch64-latest.tar.gz - except for marvell, which is missing:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# lsmod | sort
Module Size Used by
armada_thermal 20480 0
authenc 16384 1 crypto_safexcel
cfg80211 434176 0
crypto_safexcel 147456 0
fuse 139264 1
libdes 24576 1 crypto_safexcel
loop 28672 0
mdio_i2c 20480 1 sfp
mvmdio 16384 0
mvpp2 131072 0
phylink 57344 1 mvpp2
rfkill 32768 2 cfg80211
sbsa_gwdt 16384 0
sfp 40960 0
')
However, modprobe marvell followed by systemctl restart systemd-networkd.service doesn't change anything - networkctl list still reports no-carrier for eth2. So I don't know if this module is relevant here
.- I have extracted both default initramfs images' contents and compared them. The only difference is that the newly-generated one has a couple files more in /usr/lib/modules/.
Directory NEW/ below has the contents of the re-generated /boot/initramfs-linux.img and BCK/ has the contents of /boot/initramfs-linux.img as it came with ArchLinuxARM-aarch64-latest.tar.gz:
$this->bbcode_second_pass_code('', '
$ diff -r NEW/ BCK/
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/kernel: drivers
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.alias.bin
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.builtin.alias.bin
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.builtin.bin
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.dep.bin
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.devname
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.softdep
Only in NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH: modules.symbols.bin
')
And in the new NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/kernel/drivers/net/ethernet/marvell there's an mvmdio.ko module, which isn't there in the ArchLinuxARM-aarch64-latest.tar.gz's /boot/initramfs-linux.img:
$this->bbcode_second_pass_code('', '
$ diff -r --new-file NEW/ BCK/
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/kernel/drivers/net/ethernet/marvell/mvmdio.ko and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/kernel/drivers/net/ethernet/marvell/mvmdio.ko differ
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.alias.bin and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.alias.bin differ
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.builtin.alias.bin and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.builtin.alias.bin differ
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.builtin.bin and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.builtin.bin differ
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.dep.bin and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.dep.bin differ
diff -r --new-file NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.softdep BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.softdep
1d0
< # Soft dependencies extracted from modules themselves.
Binary files NEW/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.symbols.bin and BCK/usr/lib/modules/6.2.1-1-aarch64-ARCH/modules.symbols.bin differ
')
So it looks like this new content in /boot/initramfs-linux.img (again: without me having changed anything in the system prior to running mkinitcpio -p linux-aarch64) breaks the eth2 interface
?Does anyone know why, and maybe has an idea how to fix it so that running mkinitcpio -p linux-aarch64 doesn't lead to a broken network after reboot?
As the http://os.archlinuxarm.org/os/mvebu/boo ... -image.bin u-boot firmware is quite old (2018-04-03) I also tried replacing it with https://solid-run-images.sos-de-fra-1.e ... icrosd.bin (2020-12-01). Although this is a good idea in general (e.g. SATA devices are detected with the new firmware, unlike with the old one) it doesn't change anything in regard to the issue being discussed here. Using the new firmware the original initramfs from ArchLinuxARM-aarch64-latest.tar.gz still brings up eth2, and a re-generated initramfs still doesn't.
BTW, I also tried building the latest and greatest u-boot firmware, but it won't boot. Please see my support request on the TF-A list https://lists.trustedfirmware.org/archi ... 4EOXVIRIM/ and if you know what's the problem there I'd appreciate your help with that as well
.