Unable to update repository



  • Hi folks,

    I'm getting the following symptoms on my NanoBSD-based pfSense box equipped with a 4Gb CF (currently running rel. 2.3.3).

    I hasten to add that I had already dealt with the same update problem 2 weeks before and that, to solve it quickly, I had reinstalled pfsense writing the CF from scratch, just to experience it later again. I'm saying this to point out that the problem should be triggered by some background operation, with no specific user action, while the box and all the machines in the network are working perfectly.

    So, I'm getting the well know "unable to check update status" message from the GUI dashboard and I can't use the package manager to display installed or to install new packages ("unable to retrieve package info") and I can't even access the "update settings" subpage of the update function from the GUI to select the source ("gateway timeout").

    Trying to solve, I checked all the update-related solutions on the forum, with no success (including jimp's solution on sticky posts https://forum.pfsense.org/index.php?topic=116223.0 labelled "2.3.x "Unable to check for updates"/"Unable to retrieve package information").

    Infact, trying to execute "pfSense-upgrade -d" or "pkg update; pkg upgrade pkg", I get an "unable to update repository catalogue pfsense-core" warning and the following "unable to update pfsense repository".

    Looking at the system logs, I found the following warnings, related to attempted update operations, that seem quite strange and give me no clue:

    nginx: 2017/05/07 17:36:44 [error] 48369#100083: *167 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.0.22, server: , request: "POST /pkg_mgr_installed.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.0.235", referrer: "https://192.168.0.235/pkg_mgr_installed.php"

    nginx: 2017/05/07 17:43:33 [error] 48771#100098: *213 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.0.22, server: , request: "GET /system_update_settings.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.0.235", referrer: "https://192.168.0.235/pkg_mgr_install.php?id=firmware"

    Has anybody any ideas except reinstalling the system once again?


  • Rebel Alliance Developer Netgate

    Those log messages are timeouts where the backend didn't return a result in a timely manner. Basically, it took too long.

    What happens when you run "pkg update -f" from the command line on that system?

    It could be that your CF is too slow, or it's failing.



  • Hi jimp,
    thanks for your prompt and kind reply.

    If I execute "pkg update -f" I get the same "unable to update" on "repository pfSense-core" and "repository pfSense" as before, after a long, long time (1h) waiting for the specific catalogue.

    In order me to check for the correct R/W operation of the CF, I copied a large file on it via FTP with no hassle, besides that I can recall there was no error in writing the full 4GB image file on it when I reinstalled pfSense 2wks ago.

    From my perspective, every service in the network is working fine with no slowdown, except when I try to execute the various "update operations" that I have already described, that eventually fail.

    In reading the warnings in the system log, I was mostly surprised in reading a strange url path, while I'm still wondering why I cannot access the "update settings" subpage getting a "gateway timeout"; that led me to think of a trouble on the new update/package system, that has been recently changed.



  • In the meantime, in order to address this issue thourougly, I cloned my pfSense system, updating it to 2.3.4 (so we can exclude any CF problem) and installing on a VMWARE esxi 6 and - again after almost 2 weeks - I get similar symptoms: the update check on the GUI, the access to the update page on the GUI, the 'pkg update' from shell have become extremely slow (>5 min) even when executed on a fast piece of hardware; IMHO this explains all the time-outs / aborted procedures previously found on the other low-power nanobsd appliance.
    I still have to figure out the cause of this delayed and weird behavior…



  • Same issues here. Everything related to packages seems very slow and/or just does not work in 2.3.4.
    Running on fast hardware.



  • Glad its not just me.

    I even resorted to "pkg-static upgrade -f" just to make sure nothing had become corrupted, it took about 4 hours to download and reinstall 10MiB.

    It definitely seems to be something very wrong in the package manager itself.  Its not working at all from the UI but that is probably timeouts due to how very slow its running.

    Downloading something via curl on the command line does my line speed.  Downloading from the mirror site directly works fine.  All other functionality of pfSense is absolutely fine.