Unable to check for updates

bimmerdriver

I was running the most recent snapshot, as of a few days ago. On the GUI, I was getting the message, "Unable to check for updates". When I checked from the console, I was getting the message, "Another instance is already running... Aborting!". This was occurring even after rebooting and trying to check for updates using the console.

I reverted to the previous clean installation from March 7 and I'm getting the same thing. For a while, I was also getting this on a system running 2.6.0, but it's working fine now.

Anyone else experiencing this?

NRgia

@bimmerdriver said in Unable to check for updates:

I was running the most recent snapshot, as of a few days ago. On the GUI, I was getting the message, "Unable to check for updates". When I checked from the console, I was getting the message, "Another instance is already running... Aborting!". This was occurring even after rebooting and trying to check for updates using the console.

I reverted to the previous clean installation from March 7 and I'm getting the same thing. For a while, I was also getting this on a system running 2.6.0, but it's working fine now.

Anyone else experiencing this?

Try to restart unbound from CLI using the following:

unbound-control -c /var/unbound/unbound.conf reload

then try to update again

If it's still not working run from CLI the following:

pkg-static -d update

and try to update again

Then if it's still not working, I'm out of suggestions, taking in account that your internet connection is working for other sites.

bimmerdriver

@nrgia said in Unable to check for updates:

Try to restart unbound from CLI using the following:
unbound-control -c /var/unbound/unbound.conf reload
then try to update again

If it's still not working run from CLI the following:
pkg-static -d update
and try to update again

Then if it's still not working, I'm out of suggestions, taking in account that your internet connection is working for other sites.

I left the system alone for a few hours, came back and it was showing an available update, so I tried to update. It didn't proceed and eventually there was a message, "504 Gateway Time-out". I tried executing the unbound command. Afterwards, it said the same message as before, "Unable to check for updates", so I tried the second command. It ended up with "504 Gateway Time-out".

My internet connection is working fine. I have several other instances of pfSense running different versions with no problem. I'm currently only having a problem on this system.

bimmerdriver

Further to the previous post, there is a problem on 2.7.0-DEVELOPMENT with the IPv6 gateway and DHCPv6, even though IPv6 is otherwise working. I disabled IPv6 in System Advanced Networking IPv6 Options and tried again. This time I was able to check for updates and apply a new update. I did not expect that. The system is on the latest snapshot. When I enabled IPv6, the gateway problem was still present, not surprisingly.

rolstone

@bimmerdriver
You can check "Prefer IPv4 over IPv6" also can work!

Gertjan

@rolstone

Or leave all these sttings as they are, and 'tell' pfSense that only the 'pkg' system should prefer IPv4.

See https://forum.netgate.com/topic/171045/he-ipv6-tunnel-and-pfsense-update/2?_=1648453322965

I've modified the "/usr/local/libexec/pfSense-upgrade" file so the forceipv4 option is set by default.

This doesn't seem to be a 2.7.0 dev version issue, as I'm using 2.6.0, an since a couple of days this issue suddenly appeared.
This looks to me more an IPv6 routing issue 'some where on the Internet'.

bimmerdriver

@gertjan Thank you for the reply and the suggestion to prefer IPv4 for updates. I was away this week, but update seems to be working fine now, so I think your idea that there may have been a routing problem might be right. I'll keep an eye on this and will report back if the proble, returns.

bimmerdriver

@rolstone One of the main reasons I'm running this development system is to keep an eye on IPv6 functionality, because it's been problematic. Setting the system to prefer IPv4 in general will make it less obvious when there are problems with IPv6.

Gertjan

@bimmerdriver said in Unable to check for updates:

so I think your idea that there may have been a routing problem might be right.

A Netgate fellow here on the forum confirmed that Netgate had a 'IPv6' issue. It's repaired.

Gertjan

@bimmerdriver said in Unable to check for updates:

@rolstone One of the main reasons I'm running this development system is to keep an eye on IPv6 functionality, because it's been problematic. Setting the system to prefer IPv4 in general will make it less obvious when there are problems with IPv6.

IPv6 works well since ..... 2010 or so.
Most OSes ( all the big ones ) use IPv6 by default, and fall back to IPv4 if IPv6 doesn't seem to work.
On the other hand : good old IPv4 isn't dead yet, as the bigger part of the top 1000 world web sites isn't reachable yet with IPv6.

IPv6 has to be understand by the ones who implement it. In most cases, that's you and me @work or @home. And yes, there are many (big !) ISPs out there that "don't do it" or far worse, do it totally wrong.

I'm posting on this forum ( also hosted by Netgate ^^ ) only using IPv6 for many years now.

Btw : the real issue with "Unable to check for updates", the subject of this tread, is that the upgrade/update script can use IPv4 or IPv6, but "can't fall back to the other one", if the first one doesn't work out.
In this case, IPv6 is default, so it tries to connect to the IPv6 server address. And then it just 'hangs' and fails. Forcing it too use IPv4 ( see posts above ) worked in this case.

bimmerdriver

@gertjan I agree that IPv6 support in OSes has been solid for a long time. However, what has not been solid is prefix delegation and router announcement. My ISP uses Alcatel/Nokia and Juniper equipment and requires the use of "Do not wait for a RA". I was one of the early testers of this switch. This has been broken numerous times over the years, which is why I keep an eye on IPv6.