![]() |
Armbian 5.4.43: Network is unreachable; Red LED blinking; RNG failure? - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85) +--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88) +--- Thread: Armbian 5.4.43: Network is unreachable; Red LED blinking; RNG failure? (/showthread.php?tid=10799) |
Armbian 5.4.43: Network is unreachable; Red LED blinking; RNG failure? - aves - 07-22-2020 # I am working on a new installation of Armbian for Rock64, and have been having an inordinate amount of trouble # I was working and struggling mightily with getting full disk-encryption on the device. # I now have another, more low-level problem: connecting to the internet. # I don't know what is causing it, but suspect a random number generator required for ethernet may have stopped functioning. =================================================================================================== # I verified the image I am using is the same one available at this time from: $ wget https://dl.armbian.com/rock64/Buster_current $ if [[ `md5sum file_i_used.img | cut -d ' ' -f1` == `md5sum Armbian_20.05.2_Rock64_buster_current_5.4.43.img | cut -d ' ' -f1` ]]; then echo MATCH; else echo DIFFERENT; fi | -> MATCH # It's md5 checksum: $ md5sum Armbian_20.05.2_Rock64_buster_current_5.4.43.img | cut -d ' ' -f1 | -> e0202e3887c8784d456eeab6f6ab2b11 =================================================================================================== # I discovered the internet connection problem quickly upon trying: $ sudo apt install (package names) | -> Could not resolve 'deb.debian.org' | -> (With lots of other probably-irrelevant information) # My first thought is to test network connections with ping: $ ping 9.9.9.9 | -> connect: Network is unreachable $ ping 192.168.1.254 | -> connect: Network is unreachable # systemctl --state=failed reveals that haveged.service failed. # grepping for the reason yields: $ systemctl --state=failed | grep haveged.service | -> haveged.service loaded failed failed Entropy daemon using the HAVEGE algorithm # Checking journald, grepping for the relevant info I found: $ sudo journalctl -xe | grep ip-config | -> (...junk information removed...) device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') | -> (...junk information removed...) device (eth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed') # I also check /var/log/syslog # grepping for haveged yields: $ sudo cat /var/log/syslog | grep haveged | -> (...junk information...) "haveged[776]: haveged: Couldn't initialize HAVEGE rng 9" | -> (...junk information...) "haveged[776]: haveged starting up" | -> (...junk information...) "systemd[1]: haveged.service: Main process exited, code=exited, status=1/FAILURE" | -> (...junk information...) "systemd[1]: haveged.service: Failed with result 'exit-code'." =================================================================================================== # My next thought is to check the interfaces # eth0 appears to be up: $ sudo ifconfig | -> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 | -> RX packets 1 bytes 118 (118.9 B) | -> TX packets 245 bytes 42062 (41.0 KiB) # Why not try to stop and restart it? $ sudo ifdown eth0 | -> ifdown: unknown interface eth0 # It's still there: $ sudo ifconfig | -> (eth0 still listed) # Can I stop and restart the loopback interface? # I can: $ sudo ifdown lo | -> echo $? -> 0 $ sudo ifconfig | -> (lo not listed) $ sudo ifup lo | -> echo $? -> 0 $ sudo ifconfig | -> (lo listed) # I add the following lines to both the /etc/network/interfaces and /etc/network/interfaces.default files, # but nothing changed. This appears to be a pretty basic configuration So I don't know why: "auto eth0" " allow-hotplug eth0" " iface eth0 inet dhcp" =================================================================================================== # Something else new that caught my eye is that the board's red LED is blinking in a rhythm suggestive of the human heartbeat. # I found this page regarding the LED, but that's all, and there's not much indication of what they really mean: # https://forum.pine64.org/showthread.php?tid=5847 # I definitely don't have any heartbeat sensors attached, and I tried writing the same image to an SD card with the same results: $ cat /sys/devices/platform/leds/leds/{standby,power}/trigger | egrep -o '\[\w+?\]' | -> [heartbeat] | -> [mmc0] # The led indicating an ethernet cable is blinking normally # I poked around using commands like the following to try and find ethernet-related LEDs but found nothing suggestive of ethernet: $ find /sys/devices/platform/leds -type f | -> nothing interesting $ find /sys/firmware/devicetree/base/leds -type f | -> nothing interesting =================================================================================================== # Upon searching duckduckgo some more I find little that appears relevant # This was one of the few things that looked promising: # https://raspberrypi.stackexchange.com/questions/14101/connect-network-is-unreachable-on-a-working-connected-wlan0-interface#14107 # So I check the routing table: $ sudo route -n | -> Destination Gateway Genmask Flags Metric Ref Use Iface | (None listed) # Attempt to add default gateway manually: $ sudo route add default gw 192.168.1.254 | -> SIOCADDRT: Network is unreachable # what would raise error exit code 7? $ echo $? | -> 7 # Check routing table again -- nothing changed, still empty: $ sudo route -n | -> Destination Gateway Genmask Flags Metric Ref Use Iface | (None listed) =================================================================================================== I will post more updates as I continue to work on this problem. Can anyone help? RE: Armbian 5.4.43: Network is unreachable; Red LED blinking; RNG failure? - aves - 07-27-2020 I solved this problem by switching to the 4.4 kernel, whose md5 checksum is: dbcaa7903bfddbdb9d199624fbea801f I don't know why the 5.4 kernel caused this problem, but maybe it is because I am using an older board -- it has year # 2017 printed on the circuit board |