rpi4 lost eth0

[markmc]

I realize that no ethernet after an update is frustrating. It was for me as my Pi4 was running DNS and DHCP at home. I've realized that not I didn't have any redundancy, or any plan B in place. So my bad. Keep in mind IMO Arch is for advanced users who like to stay at the cutting edge of software. Arch users are often the first to be using a new release. Programmers and testers are human and sometimes bugs creep in. Nice thing about Arch is that the community and its vast community of experts, will have a workaround out in no time. If your device requires mission critical uptime then perhaps other distro's that could be a better fit or build in better redundancy into your systems. I've had issues with pretty much every OS I've used, and I've used most of them.

It sounds like this issue was caused by a systemd update, so distro jumping to prevent this may be a challenge.

To the dev's let me know if you want me to test anything, in my past life I was a QA tester, so I can probably contribute something at least.

[CounterPillow]

The interface rename has happened ages ago, I doubt it was a systemd update. RPi probably just did usual downstream shenanigans and refused to follow along with this until recently when someone explained to them how having interface naming depend on probe order is dumb.

The real problem here is that the rpi tarballs only match eth0 for networkd. The generic ones do it correctly: match both eth* and en*.

I also recommend that ALARM move to matching Type=ether instead.

I'd send a PR, but none of this is developed out in the open, so I can't, and even if I did it'd be ignored anyway.

[Boblepirate]

Dear all,

With the last big update, my rpi stop booting when systemd-networkd is going up. I have to start systemd-networkd during boot because I need a bridge connection on this rpi, Previously, everything works fine, but with the last big update, connection was lost during boot.

It seems that when starting systemd-networkd, the connection was released. When disabling systemd-networkd, it boot correctly (but without bridge of course!).

Can you help me ? Did someone experienced this kind of failure ?

[Edit]
When disabling ipv6 at kernel level (ipv6.disable=1 in cmdline.txt), it works as expected. I think that when systemd-networkd start, ipv6 change and that break the connection required by nfsroot.

Regards.

[graysky]

MOD NOTE - merged

[graysky]

Lots of untrue/half true info here...
1. The current aarch64 tarball (ArchLinuxARM-rpi-aarch64-latest.tar.gz) contains two network configs which cover this name change, see here.
2. Development is open, see https://github.com/archlinuxarm/PKGBUILDs
3. Many people do not read the contributing guidelines for PRs and those tend to be ignored

Bottom line: system breakage can happen. Devs do their best to minimize. This is a great community so let's continue to work together to identify and to solve problems when they surface. If ArchARM is not for you, no one is forcing you to use it. Feel free to select another distro.

[markmc]

It took me ages to get this working as I'm using netctl

What I ultimate did was

* rename /etc/systemd/network/eth0.network to /etc/systemd/network/end0.network

* modify end0.network i.e.

[Match]
Name=e*

* rename eth0 to end0 in /etc/netctl

* fix the interface in the file i.e.

Interface=end0

* rename /etc/systemd/system/multi-user.target.wants\netctl@eth0.service to netctl@end0.service

I think you can then just run systemctl restart systemd-networkd

[graysky]

You're making it way harder on yourself.... just use systemd-networkd directly. https://wiki.archlinux.org/title/System ... using_DHCP

[Boblepirate]

Concerning my previous post "Boot failed because systemd-networkd with NFSROOT system." I forgot to say that it was an armv7 not aarch64, so it's not a trouble of renaming interface I think.

[tamjan]

I stumbled here as well. Luckily that headless pi had a wi-fi connection as a backup. I resorted to setting net.ifnames=0 for now. Thanks.

[andiling]

Does anyone know what end means? I know eno, ens, enp, enx and eth. Shouldn't it be rather eno (for on-board device)?