Pkg tool needs some common sense?
-
I have complained about the idiotic timeout ever since pkg has been introduced in 2.3. There's a bug about it somewhere - Bug #7604 which got reopened after Bug #6594 has been "resolved". As noted there, you can CTRL+C and exit from this idiocy assuming you have serial console access.
I cannot even trace where do those insane cumulative timeout values come from; at one time, I managed to get some timeout value dropped from 300 to 60 secs, assuming this should help significantly, but turned out that it was only used for the GUI. And even there, it's multiplied by a factor of 15 due to some whacky retries or god knows what. The timeout values in /usr/local/sbin/pfsense-upgrade clearly are totally useless and not honored at all, or the manpage gets it wrong and the FETCH_TIMEOUT is in minutes instead of seconds.
Otherwise, "intelligence" and pkg does not go together, and FreeBSD seems to be extremely unlucky when it comes to package managers. First the PBI junk, now this.
During the 4 hours, there was no firewall active, I had e.g. login attempts to sshd from internet bots, the firewall was down because the pfblockerng tables were none existant due to waiting for the pkg restore process.
This is Bug #6028. Should be kinda prioritized, instead of rotting there.
-
While I hear ya on the timeouts.. It has always been recommended to remove packages before upgrade..
https://doc.pfsense.org/index.php/Upgrade_Guide
"It is always safest to remove packages before upgrading to a new major release. Packages will be reinstalled afterward, but are frequently a source of problems. To ensure a smooth upgrade, note the installed packages, remove them, perform the upgrade, and then reinstall whichever packages are necessary. " -
That doesn't help much either. It still takes ~30 minutes because pkg tries to fetch the packages info no matter whether you have something installed or not. IOW, that goddamn tool is absolutely useless for any offline work.
-
as dok stated that wouldnt have helped.
-
The problem comes from libfetch (it uses an imported version of the library) as far as I know. Libfetch has a global timeout that can be configured but no provisions for configuring a specific IPv6 -> IPv4 fallback timeout in case IPv6 connections are not working.
-
You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NOThat might mess with the GUI updater though, use with care.
-
There is also a 'prefer IPv4' checkbox in the system/advanced settings.. might be safer assuming it solves this..
-
@kpa:
You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NOThat might mess with the GUI updater though, use with care.
Maybe this should automatically be done by /etc/rc.bootup "just in case" and then removed after platform_booting is false? Or, try to do some simplye connectivity checks to whatever URL is specified in pfSense-repo.conf … e.g.
- test to see if its DNS can be resolved and then
- test if it's pingable
before trying to do anything whatsoever with remote pkg commands?
-
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
-
@yon:
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
I must have two very strange systems running 2.4.1 then, IPv6 is working fine on both of them, one using statics and one using DHCP6.
-
@yon:
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
This is NOT the thread for debugging your broken 12WAN setups. Kindly leave it alone.
-
Snigger… ;D
-
@yon:
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
This is NOT the thread for debugging your broken 12WAN setups. Kindly leave it alone.
Are there any rules to limit the number of use? Is this a child's toy? Not a professional tool？ ???
I would like any product to be tested in a complex and rigorous environment in order to find possible problems, rather than fear of problems and not dare to use. -
No doubt you would like that for free, too?
-
@yon:
@yon:
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
This is NOT the thread for debugging your broken 12WAN setups. Kindly leave it alone.
Are there any rules to limit the number of use? Is this a child's toy? Not a professional tool？ ???
I would like any product to be tested in a complex and rigorous environment in order to find possible problems, rather than fear of problems and not dare to use.Perhaps your requirements need professional support, here's the link to enable you to purchase it. https://www.pfsense.org/get-support/
-
At least that support will come without all the snipey comments and abuse. Probably a good buy…
-
@kpa:
You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NOThat might mess with the GUI updater though, use with care.
excellent thank you.
I will see if I can get someone to add options for this in the GUI.
-
@yon:
yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.
I dont blame blame 2.4.1 for the ipv6 issue, it was down to an exotic config I had in place, and was just coincidence this is the first time I have ran a restore with that config which broke ipv6.
My ipv6 has been fine since I fixed the config issue. I waited to fix it as was advised in the pfsense UI to not make any config changes with a config restore in process.
-
@kpa:
You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NOThat might mess with the GUI updater though, use with care.
excellent thank you.
I will see if I can get someone to add options for this in the GUI.
OK Chris, I've added the two you mentioned in the email, threw me a bit as they are ENV vars now, no longer in a conf file!
Do you or anyone else want other vars added, the two that shout at me are these:
FETCH_RETRY: integer
Number of times to retry a failed fetch of a file. Default:
3.FETCH_TIMEOUT: integer
Maximum number of seconds to wait for any one file to down-
load from the network, either by SSH or any of the protocols
supported by fetch(3) functions. Default: 30. -
thanks bud, I will give it a whirl later today :)
