Core 170 test on aarch64

Upgrade to Core 170 (testing) completed on nanopi R1SH5. /boot remains 91% full and similar could be anticipated for other aarch64 SBC, but the system reboots OK.

nanopi R1SH5 is barely usable with IPFire, repetitively losing the green0 interface

Could you provide more details? How often to you lose the green interface? Any there any errors or info in the log files? How is the green connected to the R1SH5?

1 Like

I made that comment primarily to discourage IPFire users from purchasing the model. Although it is out of production, it is probably still acquirable s/hand or new from online vendors. It was produced with only 512 MB RAM, making it unsuitable for many additional functions.

As with all nanopi, the LAN socket is onboard. It is implemented as an onboard, USB connected RTL8153, which also limits throughput to 320 Mb/s.

[root@briarh5 ~]# cat /var/log/messages | grep -e green0
Aug 15 01:55:34 briarh5 vnstatd[4314]: Monitoring (4): red0 (1000 Mbit) imq0 (1000 Mbit) green0 (10 Mbit) blue0 (1000 Mbit)
Aug 16 00:59:12 briarh5 vnstatd[18368]: Monitoring (4): red0 (1000 Mbit) imq0 (1000 Mbit) green0 (10 Mbit) blue0 (1000 Mbit)
Aug 17 00:44:49 briarh5 vnstatd[1184]: Monitoring (4): red0 (1000 Mbit) imq0 (1000 Mbit) green0 (10 Mbit) blue0 (1000 Mbit)
Aug 18 02:01:58 briarh5 vnstatd[19850]: Monitoring (4): red0 (1000 Mbit) imq0 (1000 Mbit) green0 (10 Mbit) blue0 (1000 Mbit)
Aug 18 17:05:24 briarh5 dhcpd: No subnet declaration for green0 (no IPv4 addresses).
Aug 18 17:05:24 briarh5 dhcpd: ** Ignoring requests on green0. If this is not what
Aug 18 17:05:24 briarh5 dhcpd: to which interface green0 is attached. **
Aug 18 17:51:20 briarh5 dhcpd: No subnet declaration for green0 (no IPv4 addresses).
Aug 18 17:51:20 briarh5 dhcpd: ** Ignoring requests on green0. If this is not what
Aug 18 17:51:20 briarh5 dhcpd: to which interface green0 is attached. **
Aug 19 01:04:12 briarh5 vnstatd[17412]: Monitoring (5): red0 (1000 Mbit) imq0 (1000 Mbit) green0 (1000 Mbit) eth0 (1000 Mbit) blue0 (1000 Mbit)
Aug 19 01:04:12 briarh5 vnstatd[17412]: Interface “green0” disabled.

Display, via UART, during boot invariably contains:

“interface green0 does not exist”

bootlog contains:
[ 7.641532] usbcore: registered new interface driver cdc_ether
[ 7.655587] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 7.656638] usb 1-1: reset high-speed USB device number 2 using ehci-platform
[ 7.683917] usbcore: registered new interface driver r8153_ecm
[ 7.800012] r8152 1-1:1.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00
[ 7.800054] r8152 1-1:1.0 (unnamed net_device) (uninitialized): Random ether addr 9e:6f:b4:c0:5f:85

If “setup” is run to delete, then re-instate green0, then it will run for some time, before downloads start being intermittent.

Ahhh! Got it! I thought the first post was a call for assistance.

1 Like

Hi,

just a brief comment for the records: Core Update 170 increases the size of /boot to cope with that, but this unfortunately only applies to new installations, since we cannot modify the partition table out of a running system.

Thanks, and best regards,
Peter MĂĽller

Peter,

Thanks for that update.

I tried a fresh install of core 170 (testing), rather than resizing partitions. One step forward, one back:

  • green0 (USB RTL 8153) now reliably found
  • red0 never found - no suitable module in /lib/modules/5.15.59-ipfire/kernel/drivers/net/ethernet/allwinner/
  • yet module dwmac-sun8i being loaded from somewhere

I’ll submit a bug report

1 Like