Access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or direct
-
Hi all,
I know there are many threads on the subject but none seem to fix my problem.Enter an option: 13 >>> Updating repositories metadata... Updating pfSense-core repository catalogue... pkg-static: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory pkg-static: https://pkg.pfsense.org/pfSense_v2_4_3_amd64-core/meta.txz: Network is unreachable repository pfSense-core has no meta file, using default settings pkg-static: https://pkg.pfsense.org/pfSense_v2_4_3_amd64-core/packagesite.txz: Network is unreachable Unable to update repository pfSense-core Updating pfSense repository catalogue... pkg-static: Repository pfSense load error: access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or directory pkg-static: https://pkg.pfsense.org/pfSense_v2_4_3_amd64-pfSense_v2_4_3/meta.txz: Network is unreachable repository pfSense has no meta file, using default settings pkg-static: https://pkg.pfsense.org/pfSense_v2_4_3_amd64-pfSense_v2_4_3/packagesite.txz: Network is unreachable Unable to update repository pfSense Error updating repositories! pfSense - Netgate Device ID: cdff5225c84a915d19fb
After trying a few solutions, I decided to do a clean install and then restore my config. Sadly, the problem persists. I am able to query the server from the firewall itself and from a host so I'd like to think my DNS is OK.
: dig _https._tcp.pkg.pfsense.org SRV ; <<>> DiG 9.11.2-P1 <<>> _https._tcp.pkg.pfsense.org SRV ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5841 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_https._tcp.pkg.pfsense.org. IN SRV ;; ANSWER SECTION: _https._tcp.pkg.pfsense.org. 52 IN SRV 10 10 443 files00.netgate.com. _https._tcp.pkg.pfsense.org. 52 IN SRV 10 10 443 files01.netgate.com. ;; AUTHORITY SECTION: pfsense.org. 116 IN NS ns2.netgate.com. pfsense.org. 116 IN NS ns1.netgate.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 17 21:09:50 CEST 2018 ;; MSG SIZE rcvd: 181
The file does not exist:
: ls -ld /var/db/pkg/repo-pfSense-core.sqlite ls: /var/db/pkg/repo-pfSense-core.sqlite: No such file or directory
I'm guessing that's where the problem lies but it still is missing after a clean install so now what?
Any advice would be welcome.
Thanks!
-
I am still having the same problem so I installed pfsense in a VM to check the differences.
The VM works fine and can see "available packages". After making sure my DNS resolver was setup identically, I still couldn't see any packages listed.
After looking at my routing table however, I came accross something that to my noob mind makes no sense.
I have a WAN (em0), a LAN (em1), a WIFI (em2) and a VPN connection (ovpnc5) through which I try and have all my traffic go through.
Destination Gateway Flags Netif Expire default 10.4.54.36 UGS lo0 10.4.0.0/16 10.4.0.1 UGS ovpnc5 10.4.0.1 link#10 UH ovpnc5 10.4.54.36 link#10 UHS lo0 10.20.30.40 link#2 UHS lo0 10.20.30.40/32 link#2 U em1 81.243.127.186 link#9 UHS lo0 127.0.0.1 link#6 UH lo0 192.168.1.0/24 link#2 U em1 192.168.1.1 link#2 UHS lo0 192.168.2.0/24 link#3 U em2 192.168.2.1 link#3 UHS lo0 217.116.148.10 link#9 UH pppoe0
I don't understand why the default gateway tries to go through the lo0 interface and not the ovpnc5 interface. I still get a DNS response when querying from the firewall or clients on the LAN.
What am I doing wrong? I'm going over each setting comparing a vanilla installation and what I currently have but it will take some time and I am puzzeled by the routing table.
As always, any advice is welcome! :)
Thanks. -
So I keep searching for a solution and can't seem to get anyone interested in my issue.
The Routing issue was fixed by a reboot.
From the router, I can do DNS queries so I'm going to rule out DNS as being a problem.
[2.4.3-RELEASE][admin@rtr.lan]/root: dig google.com +short 216.58.204.46
It seems however, that I am unable to connect to a remote site from the firewall.
[2.4.3-RELEASE][admin@rtr.lan]/root: curl -vvv https://google.com * Rebuilt URL to: https://google.com/ * Trying 216.58.204.46... * TCP_NODELAY set * Immediate connect fail for 216.58.204.46: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server
I've tried a bunch of permissive rules in my 'LAN rules' but I just can't seem to get it to work.
Can anyone offer some advice?

 -
Hi.
I guess rebooting ones more won't help you.
What will help is ditching your setup.
A clean pfSense does :
[2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: curl -vvv https://google.com * Rebuilt URL to: https://google.com/ * Trying 2a00:1450:4007:80c::200e... * TCP_NODELAY set * Connected to google.com (2a00:1450:4007:80c::200e) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /usr/local/share/certs/ca-root-nss.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com * start date: Apr 17 14:02:11 2018 GMT * expire date: Jul 10 12:40:00 2018 GMT * subjectAltName: host "google.com" matched cert's "google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x803a94580) > GET / HTTP/2 > Host: google.com > User-Agent: curl/7.58.0 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 301 < location: https://www.google.com/ < content-type: text/html; charset=UTF-8 < date: Mon, 21 May 2018 17:02:36 GMT < expires: Wed, 20 Jun 2018 17:02:36 GMT < cache-control: public, max-age=2592000 < server: gws < content-length: 220 < x-xss-protection: 1; mode=block < x-frame-options: SAMEORIGIN < alt-svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35" < <title>301 Moved</title> # 301 Moved The document has moved [here](https://www.google.com/). * Connection #0 to host google.com left intact
so consider your system broke. Clean it up and you'll be fine ;)
-
Thanks for the reply Gertjan,
I was doing my best not to have any down time. My wife hates it when I tinker and block access to instagram! ;)Thanks for your advice.
-
@gertjan said in Access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or direct:
curl -vvv https://google.com
This might be a late response, but I experienced the exact same issue lately on one of our systems. After trying to follow all the hint in the different groups I was close to giving up. Finally - the routing caught my attention. I wasn't even able to ping well know hosts from the shell even so the system itself was working and routing without any issues!
We have gateway groups configured - so I did a wild guess and set one of the gateways as default. Miracle - pkg update -f goes through. Enabling gateway group - still working.
I have no real explanation for that behaviour - but it seemed that the fw itself lost connectivity somehow. No need to reboot and no downtime - luckily ;-)
-
Repo broke. Port forwards broke. IPv6 RA speaking in tongues.
@roadrunner51 said in Access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or direct:
We have gateway groups configured - so I did a wild guess and set one of the gateways as default. Miracle - pkg update -f goes through. Enabling gateway group - still working.
I have no real explanation for that behaviour - but it seemed that the fw itself lost connectivity somehow. No need to reboot and no downtime - luckily ;-)
You, sir, are a gentleman and a scholar.
-
This was definitely a problem in 2.4.4, I hit that on a few systems, no default gateway set or a bad default.
But it should have been OK on 2.4.3 and should be fixed in 2.4.4p1.Steve
-
was banging my head with this issue for couple of hours. Done couple of things.. Somehow the Routing experiment saved me this time, just don't ask me how.
I have an actual working Router working and paralleled the pfsense VM for experiment. I changed the default Gateway from WAN to LAN segment and it worked. So basically it wont get packages through it's own WAN, I need to deploy another router for this?? -- WHAT THE FUN..!!
updating this here, since it looks like a temp issue with no fix yet and somebody might get an workaround if google points here. -
@roadrunner51 Just wanted to thank you for this solution. Fixed my problem.