NanoBSD upgrade package reinstallation fails.

  • I'm testing out pfSense 2.1, nanoBSD 1G on an internal USB stick, on a couple of Intel server boxes (ServerBoard 5000PSL with dual dual-core 3.2GHz Xeons, on-the-motherboard USB socket) for a multi-wan and HA setup.

    Twice now, when upgrading to latest with the autoupdater I've lost all installed packages (and twice is all of the autoupdates I've done thus far…..).  Here's the relevant section from the serial console log:

    One moment please, reinstalling packages...
     >>> Trying to fetch package info...
     >>> Unable to communicate with Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity.
    Starting syslog...done.

    Ok, so is there a way of getting this to install once the system is 'fully up' since I can easily ping from the web GUI:

    PING ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=47 time=44.056 ms
    64 bytes from icmp_seq=1 ttl=47 time=43.627 ms
    64 bytes from icmp_seq=2 ttl=47 time=43.753 ms
    --- ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 43.627/43.812/44.056/0.180 ms

    Is there a timeout or something that can be adjusted, or why isn't the box seeing when it needs to see it during package reinstall?

    I'm on the current version:

    2.1-RC0 (amd64)
    built on Thu Jul 25 16:29:19 EDT 2013
    FreeBSD 8.3-RELEASE-p8

  • Rebel Alliance Developer Netgate

    What kind of WAN do you have? Static IP? DHCP? PPPoE?

    What are your DNS servers set to? Manually configured IPs? Or obtained via DHCP/PPPoE?

  • First, thanks for the reply.

    Second, all DNS servers are set manually, and the LAN and both WANs have static IPs.  No DHCP running for this box.

    Are there any logging options I can enable or log files I can send that will assist in further troubleshooting?

    The interfaces are connected to three GigabitEthernet ports on a Cisco 7609 router, Supervisor 720, IOS 12.2(33)SRD.  The WAN ports are 1000Base-SX Intel 'legacy' PRO/1000 PCI-X cards, and the LAN is an on-motherboard Intel PRO/1000.  Portfast is not enabled on the 7609, so the ports go through spanning-tree negotiation (perhaps the package re-install phase is happening before the gig ports on the 7609  fully transition into spanning-tree forwarding state? I can enable portfast for testing…..).

    Target for this pfSense is to be one of a pair of HA firewalls with WAN load balancing for traffic up to 1Gb/s.  The other box has a dual port SysKonnect SX card (and I chose pfSense over Vyatta in part because the Alt-Q drivers' support of the SK984x is usable in pfSense and not even present in Vyatta, and HA and multi-WAN seem to be far more robust in pfSense, many thanks to the developers!).

    I chose the nanoBSD variant for two reasons: one, these boxes had no hard drives but have on-motherboard USB ports; two, a mostly read-only operation really appeals to my IT security side.

    Anyway, let me know if you need more info or have options you'd like me to test.

  • Rebel Alliance Developer Netgate

    I'd say it's the lack of portfast causing you to not have connectivity while booting if it's blocking your port for STP.

    On something like ALIX the boot is slow enough that it doesn't matter but on a higher-end machine it gets to that point before the port has a chance to transition.

  • Portfast results:

    Well, I watched the Cisco 7609's console and during the post update reboot did not see the port cycle with portfast enabled.  It successfully re-installed a package this time.  It was kindof odd to not see the port go down then back up; I'm going to try that again with portfast off to make sure it 'leaves the bridge' when the box reboots.

    If so, then portfast fixes it; good thing I don't need bridged interfaces.

    Yes, this 3.2GHz twin dual-core box boots very quickly, even from USB flash, and without portfast the typical cisco port won't go into spanning-tree forwarding mode for thirty seconds or more.

Log in to reply