SBC Firmware Update
-
I am currently trying to update a Duet MB6HC with a raspberry pi. However, when trying to run the sudo apt update command it seems the pi is unable to connect to any of the connections needed when grabbing the updated firmware. Is this an ISP issue? I have had this issue on two separate networks, but don't know. Any insight would be appreciated. (See below for the error output from Powershell). This happens when trying to update from a setup currently running 3.3 and a setup running 3.4.1
sudo apt update
Err:1 http://archive.raspberrypi.org/debian buster InRelease
Temporary failure resolving 'archive.raspberrypi.org'
Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Temporary failure resolving 'raspbian.raspberrypi.org'
Err:3 https://pkg.duet3d.com stable InRelease
Temporary failure resolving 'pkg.duet3d.com'
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease Temporary failure resolving 'raspbian.raspberrypi.org'
W: Failed to fetch https://pkg.duet3d.com/dists/stable/InRelease Temporary failure resolving 'pkg.duet3d.com'
W: Failed to fetch http://archive.raspberrypi.org/debian/dists/buster/InRelease Temporary failure resolving 'archive.raspberrypi.org'
W: Some index files failed to download. They have been ignored, or old ones used instead. -
That seems like an ISP issue. Are you able to ping those domain names?
-
@Phaedrux Just did successful pings of all 3 domains from powershell.
ping pkg.duet3d.com
Pinging pkg.duet3d.com [134.209.94.168] with 32 bytes of data:
Reply from 134.209.94.168: bytes=32 time=106ms TTL=51
Reply from 134.209.94.168: bytes=32 time=106ms TTL=51
Reply from 134.209.94.168: bytes=32 time=106ms TTL=51
Reply from 134.209.94.168: bytes=32 time=105ms TTL=51Ping statistics for 134.209.94.168:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 105ms, Maximum = 106ms, Average = 105msPinging lb.raspberrypi.com [46.235.230.122] with 32 bytes of data:
Reply from 46.235.230.122: bytes=32 time=81ms TTL=53
Reply from 46.235.230.122: bytes=32 time=83ms TTL=53
Reply from 46.235.230.122: bytes=32 time=81ms TTL=53
Reply from 46.235.230.122: bytes=32 time=81ms TTL=53Ping statistics for 46.235.230.122:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 81ms, Maximum = 83ms, Average = 81msPinging mirrordirector.raspbian.org [93.93.128.193] with 32 bytes of data:
Reply from 93.93.128.193: bytes=32 time=81ms TTL=50
Reply from 93.93.128.193: bytes=32 time=82ms TTL=50
Reply from 93.93.128.193: bytes=32 time=82ms TTL=50
Reply from 93.93.128.193: bytes=32 time=83ms TTL=50Ping statistics for 93.93.128.193:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 81ms, Maximum = 83ms, Average = 82ms -
Ok, now can you ping them from the Pi?
-
@Andrew2087 It's more important to check if you can ping any of the servers (archive.raspberry.org or pkg.duet3d.com) from the Pi itself. It sounds like the network setup on the Pi is faulty or incomplete. If you can ping those servers, check if the configured date/time is correct on the Pi by sending
timedatectl
. -
@chrishamm @Phaedrux I am unable to ping anything from the pi, and the configured date/time was incorrect (although I assume that is because it can't connect to the necessary connection to update the date/time).
-
@Andrew2087 Yes, that is correct, it should update itself once it establishes a connection to the internet. Are you sure it gets an IP address? What's the output of
ip addr
? -
@chrishamm It does the following:
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:2d:9d:0d brd ff:ff:ff:ff:ff:ff
inet 192.168.60.204/24 brd 192.168.60.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fd51:42f8:caae:d92e::ff/64 scope global dadfailed tentative noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::db7f:15dd:42d7:bc7a/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:78:c8:58 brd ff:ff:ff:ff:ff:ff -
@Andrew2087 Looks like something is up with your IPv6 configuration, maybe try to disable it: https://cwesystems.com/?p=231 What's the output of
ip route
andcat /etc/resolv.conf
? -
@chrishamm Before disabling IPv6
ip route
default via 192.168.1.1 dev eth0 src 192.168.60.204 metric 202
192.168.1.1 dev eth0 scope link src 192.168.60.204 metric 202
192.168.60.0/24 dev eth0 proto dhcp scope link src 192.168.60.204 metric 202cat /etc/resolv.conf
Generated by resolvconf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fd51:42f8:caae:d92e:: 100:After disabling ipv6:
ip route
default via 192.168.1.1 dev eth0 src 192.168.60.204 metric 202
192.168.1.1 dev eth0 scope link src 192.168.60.204 metric 202
192.168.60.0/24 dev eth0 proto dhcp scope link src 192.168.60.204 metric 202cat /etc/resolv.conf
Generated by resolvconf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fd51:42f8:caae:d92e::1After disabling ipv6, I am still unable to ping anything... It still gives a "Temporary failure in name resolution" error
-
@Andrew2087 Your IP address or route is wrong, are you sure you don't have a second router on the same network? You've got everything configured for a 192.168.1 network but your IP address is 192.168.60.204. Did you modify anything in /etc/network/ before?
-
@chrishamm That was the issue, when setting the static IP for the printer, it had been set up for a different network originally, then when moved to a different network only the subnet for the static ip for the pi was updated to the 60 and not the router. THANK YOU
-
-