Bug #7345
closednanobsd upgrades still fail bacause of lacking resolv.conf
80%
Description
As I wrote in a comment to the closed bug #6557, the upgrade procedure still fails, because copying the source file of a symlink over the symlink itself does not work. The command exits with this error:
"cp: /var/etc/resolv.conf and /tmp/nanobsd_upgrade/etc/resolv.conf are identical (not copied)".
Thus we need first remove the symlink. I propose the attached patch to pfSense-upgrade script, which works for me.
Files
Updated by Brett Keller almost 8 years ago
I also ran into this issue, which broke my ability to update my NanoBSD 2.3.2_1 box to 2.3.3_1. The box in question runs neither unbound nor dnsmasq, as we have a separate DNS server on the LAN, so the fallback DNS calls to localhost mentioned in bug #6557 were failing after very long timeouts:
>>> Mounting second partition to run upgrade... done.
>>> Copying resolv.conf to upgrade partition... done.
>>> Downloading upgrade packages...
Updating pfSense-core repository catalogue...
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
Unable to update repository pfSense
All repositories are up-to-date.
pkg: Repository pfSense-core cannot be opened. 'pkg update' required
pkg: Repository pfSense cannot be opened. 'pkg update' required
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
>>> Upgrading pfSense kernel...
pkg: Repository pfSense-core cannot be opened. 'pkg update' required
pkg: Repository pfSense cannot be opened. 'pkg update' required
pkg: No packages available to upgrade matching 'pfSense-kernel-pfSense' have been found in the repositories
>>> Locking package pfSense-kernel-pfSense... done.
Failed
Thanks to Andrew Hotlab for identifying the root cause! This is the right fix, but I had to tweak your patch slightly because your call to _exec()
was missing an argument for _msg
, and _exec()
makes the assumption that the second argument will always be the log message, no matter what.
I tested my tweaked version of your patch on the box I had that was suffering from this issue, and the update was able to complete successfully. I've submitted pull request #332 on GitHub, so hopefully this should get merged and fixed shortly.
Updated by Renato Botelho over 7 years ago
- Assignee set to Renato Botelho
- Target version changed from Future to 2.3.4
Updated by Renato Botelho over 7 years ago
- Status changed from New to Feedback
PR has been merged, thanks!
Updated by Renato Botelho over 7 years ago
- Status changed from Feedback to Resolved
Fixed in 2.3.3-p1