pfSense

Just happened to me as well. Brand new SG-2440 from Netgate with 2.3.4 pre-installed. I restored a config from the old router which is also on 2.3.4 and I've been waiting for over 20 minutes and so far it just keeps looping. Going to be late to the office after waiting for this to finish.

Waiting for Internet connection to update pkg metadata and finish package reinstallationUpdating pfSense-core repository catalogue...
repository pfSense-core has no meta file, using default settings

Unable to update repository pfSense-core
Updating pfSense repository catalogue...
repository pfSense has no meta file, using default settings
Unable to update repository pfSense
Error updating repositories!

ERROR!!! An error occurred on pkg execution (rc = 70) with parameters 'update -f':
pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory
pkg: https://firmware.netgate.com/pkg/pfSense_factory-v2_3_4_amd64-core/meta.txz: No address record
pkg: https://firmware.netgate.com/pkg/pfSense_factory-v2_3_4_amd64-core/packagesite.txz: No address record
pkg: Repository pfSense load error: access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or directory
pkg: https://firmware.netgate.com/pkg/pfSense_factory-v2_3_4_amd64-pfSense_factory-v2_3_4/meta.txz: No address record
pkg: https://firmware.netgate.com/pkg/pfSense_factory-v2_3_4_amd64-pfSense_factory-v2_3_4/packagesite.txz: No address record

.Updating pfSense-core repository catalogue...
repository pfSense-core has no meta file, using default settings
Unable to update repository pfSense-core
Updating pfSense repository catalogue...

This is happening to me too, have a fresh 2.3.4 install. I will restore config from another 2.3.4 install. Sure enough hangs on boot. Is there anyway to restore a config without internet connection?

A quick workaround:

Interrupt update process with ctrl+c and enter to a shell. Then:
vi /usr/local/etc/pkg/repos/pfSense.conf

Change the "enabled" option from "yes" to "no". Save and exit. Exit the shell. On next boot the update process will fail only spending a few seconds and booting normally.

Just happened to me, moments ago.

Backup up a 2.3.4 machine (server is unstable) and replaced the server hardware with a fresh new 2.3.4 copy.
After reloading the backup config and fixing the interfaces, i´ve rebooted and the server hang

I can confirm that using @Guillem Parera workaround can make the server boot normally, apart from throwing 3-4 connection errors on boot

Same issue as above.

Experienced issues with package updates not registering. Tried to run the command from CLI and it threw this error:

Updating pfSense-core repository catalogue...
pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory

Sure enough, that file was missing and was not being regenerated. Thought to backup and restore, now I'm at the hang at boot and even after @Guillem Parera's work around, pkg will not update because that file is missing.

2 months and no word, no assignee?

Definitely confirmed as not fixed at all. The easiest way to reproduce is to exploit the pfBNG + unbound bug. Missing include file -> unbound not starting -> no DNS, cannot update repo -> hangs on boot forever until your CTRL+C and exit (that is, if you have serial console).

Reproduced on latest 2.4 snapshot with config.xml restored via USB stick during install.

Backup:
1. Backup by ticking Skip packages
2. Backup the Package Manager only

On the server where you want to restore the backup config:
1. Ensure that Installed Packages from the original machine are installed also.

Restore first the backup config (skip packages) then restore the package manager backup.

Reboot the machine.

Vincent Sencil wrote:

Backup:
1. Backup by ticking Skip packages
2. Backup the Package Manager only

On the server where you want to restore the backup config:
1. Ensure that Installed Packages from the original machine are installed also.

Restore first the backup config (skip packages) then restore the package manager backup.

Reboot the machine.

AFAICT this is completely useless exercise since the download is attempted even if no packages whatsoever are installed.

FFS it cannot be so hard to drop the timeouts to SANE values (3 minutes cumulative max. with all retries included), not 30+ minutes!!!

So I just tried again... this must be the most braindead thing ever.

Waiting for Internet connection to update pkg metadata and finish package reinstallation
Updating pfSense-core repository catalogue...
Fetching meta.txz: . done
Fetching packagesite.txz: . done
Processing entries: . done
pfSense-core repository update completed. 7 packages processed.
Updating pfSense repository catalogue...
Fetching meta.txz: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
pfSense repository update completed. 485 packages processed.
All repositories are up to date.

Updating pfSense-core repository catalogue... <--- why? You've just finished that!!!
pfSense-core repository is up to date.  <-- No shit, Sherlock!
Updating pfSense repository catalogue... <-- ZOMG.
pfSense repository is up to date. <-- ORLY? I'm shocked!
All repositories are up to date. <-- No way!

And this utter stupidity goes on, and on, and on, with every frickin' package that's supposed to be reinstalled:

Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        pfSense-pkg-AutoConfigBackup: 1.47 [pfSense]

Number of packages to be installed: 1
...
Menu items... done.
Writing configuration... done.

Next package:

Updating pfSense-core repository catalogue... <-- Are you a fsckin' Alzheimer or what?
pfSense-core repository is up to date.
Updating pfSense repository catalogue... <-- Right, definitely a severe Alzheimer.
pfSense repository is up to date.
All repositories are up to date.
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        pfSense-pkg-nut: 2.7.4_5 [pfSense]
        nut: 2.7.4_4 [pfSense]
        neon: 0.30.1 [pfSense]
        net-snmp: 5.7.3_17 [pfSense]

Number of packages to be installed: 4

OMG this just cannot be humanly possible. Update the goddamn repos ONCE! ONCE!! ONCE!!! It's just enough to do it ONCE!!! NOT once per package FFS!

Can't believe this is still a issue. :( At the very least can we just decrease the timeout to like 3mins? I would think that would be fine for all of us.

I've just come across this bug now. Most.. infuriating .. nonsense. In my case I have a working WAN, but you can't select PPPOE0 during the interface assignment post-restore, so as it stands its impossible for me to bypass a 30-45 minutes wait.

I didn't realize this was a huge issue, but I have a workaround for this.

At the moment booting appears to stop with this error, hit Ctrl+C to break out of the process
This brings you to a prompt to select the shell. Hit <Enter> which selects the default shell, /bin/sh
When you see the shell prompt again type "exit" and it will continue with the rest of the boot process.

This process works for several different errors that hang the boot process but its a great time saver for sure on this specific issue.

G Black wrote:

At the moment booting appears to stop with this error, hit Ctrl+C to break out of the process
This brings you to a prompt to select the shell. Hit <Enter> which selects the default shell, /bin/sh
When you see the shell prompt again type "exit" and it will continue with the rest of the boot process.

This doesn't work, once it starts booting it just gets back to the point where it checks the packages and hangs again. Tried this again, and does the same thing.

Still hitting this in 2.4.3.

A different workaround for those who are just trying to factory the unit:

Escape to shell, (Single user, CTRL+C)

"cp /conf.default/config.xml /conf/config.xml"

Repeated the same test with installed squid, bind packages - all good, no delay's in bootup.