Fedora 36 beta aarch64 use on RPI4, network port dead

Ask Fedora
1

I’m not sure if this is a bug in F36 aarch64 or just unexpected behavior due to it is use on a RPI4.

I love the UEFI option now available for the RPI4 (and 3)! This allows the direct use of an .iso file for the install of an OS. I started using this method with F34 aarch64 and with F35 aarch64, expected F36 to behave similarly.

It does work the same but has the oddity of never enabling the onboard ethernet port on the RPI4.

On the second ISO install screen it has the many options to choose, including setting up networking to help with a netinstall based ISOs. So far I’ve not been able to get the ethernet port to work. It doesn’t DHCP, and hard setting the IP, gateway and DNS doesn’t give a working port either.

Options tried so far:

Instead of ethernet, I enabled wireless at that same install menu location and it came up as expected and the rest of the install worked. However on reboot, the ethernet port is still not functional. The orange LED, by the jack flashes link, but the DHCP server never sees a request, and hard coding the IP doesn’t work.

Oddly, adding a USB3 2.5g dongle at this point does get discovered and is operational as a DHCP enabled ethernet port (though only at 1g speed, using the cdc_ncm driver, instead of the r8152 driver).

Lastly, I did a full F35 aarch64 ISO install and then did an upgrade to F36 beta. All the steps went smoothly but after the last reboot. the onboard enet port is not working.

This feels like a F36 beta issue but it could be some interaction with the UEFI code or the RPI4 setup. Any suggestions for resolution or more detailed tests?

2

I realized some network manager logs might be of use:

11:50 AM<info> [1649271058.7658] dhcp4 (enabcm6e4ei0): activation: beginning transaction (timeout in 45 seconds)
11:50 AM<info> [1649271058.7640] device (enabcm6e4ei0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
11:50 AM<info> [1649271058.7474] device (enabcm6e4ei0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
11:50 AM<info> [1649271058.7458] device (enabcm6e4ei0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
11:50 AM<info> [1649271058.7445] device (enabcm6e4ei0): Activation: starting connection 'enabcm6e4ei0' (38dfbecb-4900-3d41-8973-7fe9f6d11e92)
11:50 AM<info> [1649271058.7426] policy: auto-activating connection 'enabcm6e4ei0' (38dfbecb-4900-3d41-8973-7fe9f6d11e92)
11:50 AM<info> [1649271058.7391] dhcp4 (enabcm6e4ei0): canceled DHCP transaction
11:50 AM<info> [1649271058.7020] device (enabcm6e4ei0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
11:50 AM<warn> [1649271058.7013] device (enabcm6e4ei0): Activation: failed for connection 'enabcm6e4ei0'
11:50 AM<info> [1649271058.7002] device (enabcm6e4ei0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
3

This bug has been reported against kernel:

https://bugzilla.redhat.com/show_bug.cgi?id=2053729

You can track the issue here, it’s a blocker bug: Issue #709: [kernel] RPi4 wired network fails - eth0 (bcmgenet): transmit queue 1 timed out | rhbz#2053729 - blocker-review - Pagure.io

Official Rpi4 support status is discussed here: Clarification of RPi 4 support - arm - Fedora Mailing-Lists

2 Likes
4

Thanks for the info about the reported bug. It does look like the new kernel, 5.17.2, solves the problem! The mirrors don’t seem to have the new kernel yet but they will in a day or two.

1 Like