Topics

Trying to do a clean install of 17.7.5 amd64 via USB memory stick on an OPNsense Quad Core Gen3 rack appliance (4GB RAM, 2GB CF), and it fails around 77%:

Code Select Expand

Execution of the command

/usr/local/bin/cpdup -vvv -I -o /usr/share /mnt/usr/share

FAILED with a return code of 1.

< View Log >  < Mail Log >  < Retry >  < Cancel >  < Skip >


Searching the forums I found:
[WONTFIX] Boot media for 15.1.9 : error 1 at installation.
https://forum.opnsense.org/index.php?topic=307.0

Is this the same cpdup / memory exhaustion problem, and is there anything I can do to salvage this unit?  As it has aborted mid-install it no longer boots from the CF.  It was running 17.1.4 just fine prior to this.


UPDATE / SOLVED!
Choosing MBR instead of GPT got it working.

In one OPNsense 17.1.4 install I have some firewall rules that reference a Host alias which is populated with IP addresses, e.g. 192.168.5.8, 192.168.99.54, etc.

Now I have a need to apply these same rules to a network, e.g. 10.35.0.0/16.

I can of course create a new Network alias and create copies of all the relevant firewall rules, changing these copies to reference my new Network alias.

My question is whether that is the best way to do it?  Is there a performance impact from having more rules?  If instead I moved all the Hosts into the Network alias, is there a performance impact from having hosts in a network alias?  Do I lose or gain some functionality either way?

I upgraded my A10 from 16.7.5 to 16.7.8 remotely last night via SSH CLI.  No errors during the updating but the box never came back after the reboot.  I didn't have a console cable plugged in at that time unfortunately so I don't know if it reported any errors as it tried to boot.

When I arrived on site, I plugged the console cable into the A10 but could not get any response.  Eventually pulled the A10's power plug, then replugged it.  Now output appeared on the serial console.  The usual POST and OPNsense/FreeBSD boot stuff followed, kernel modules loaded, devices enumerated, etc.  Until it got to the point where it was UP'ing my interfaces... the last serial console output was about two of my three used em* interfaces now being UP.  Then silence, no response.  The OS appears to continue to boot as eventually I can ping and SSH and HTTP to the A10, and it seems to be following it's OPNsense configuration.  Looking at /var/log/system.log shows that it just kept right on booting and logging:

Code Select Expand

(snip)
Nov 22 06:34:29 OPNsense kernel: Root mount waiting for: usbus4 usbus2
Nov 22 06:34:29 OPNsense kernel: uhub2: 4 ports with 4 removable, self powered
Nov 22 06:34:29 OPNsense kernel: uhub4: 4 ports with 4 removable, self powered
Nov 22 06:34:29 OPNsense kernel: Trying to mount root from ufs:/dev/mmcsd0s1a [rw,noatime]...
Nov 22 06:34:29 OPNsense kernel: em0: link state changed to UP
Nov 22 06:34:29 OPNsense kernel: em2: link state changed to UP
*****  About here is where the serial console stops outputting.  *****
Nov 22 06:34:29 OPNsense kernel: em3: link state changed to UP
Nov 22 06:34:29 OPNsense kernel: done.
Nov 22 06:34:30 OPNsense kernel:
Nov 22 06:34:30 OPNsense kernel: em0: link state changed to DOWN
Nov 22 06:34:30 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em0'
Nov 22 06:34:30 OPNsense sshlockout[16911]: sshlockout/webConfigurator v3.0 starting up
Nov 22 06:34:30 OPNsense configd.py: [563b1c51-64da-4082-8468-30c6defac169] Linkup stopping em0
Nov 22 06:34:30 OPNsense opnsense: /usr/local/etc/rc.bootup: The command '/sbin/ifconfig 'pppoe0' inet6 -accept_rtadv' returned exit code '1', the output was 'ifconfig: interface pppoe0 does not exist'
Nov 22 06:34:30 OPNsense kernel:
Nov 22 06:34:30 OPNsense kernel: em2: link state changed to DOWN
Nov 22 06:34:30 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em2'
Nov 22 06:34:30 OPNsense configd.py: [09a8de75-38c4-4711-90e3-addbc5b2166b] Linkup stopping em2
Nov 22 06:34:31 OPNsense kernel:
Nov 22 06:34:31 OPNsense kernel: ng0: changing name to 'pppoe0'
Nov 22 06:34:32 OPNsense opnsense: /usr/local/etc/rc.bootup: The command '/sbin/ifconfig 'pppoe1' inet6 -accept_rtadv' returned exit code '1', the output was 'ifconfig: interface pppoe1 does not exist'
Nov 22 06:34:32 OPNsense kernel:
Nov 22 06:34:32 OPNsense kernel: em3: link state changed to DOWN
Nov 22 06:34:32 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em3'
Nov 22 06:34:33 OPNsense configd.py: [9ec92e6b-b17b-4575-8078-0e1e263e8156] Linkup stopping em3
Nov 22 06:34:33 OPNsense kernel:
Nov 22 06:34:33 OPNsense kernel: ng1: changing name to 'pppoe1'
Nov 22 06:34:33 OPNsense kernel: em2: link state changed to UP
Nov 22 06:34:33 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup start em2'
Nov 22 06:34:34 OPNsense configd.py: [19561326-c76a-4047-a362-1c6295b7c439] Linkup starting em2
Nov 22 06:34:34 OPNsense kernel: em0: link state changed to UP
(snip)

I tried rebooting a couple of times, and each time the serial console goes silent and unresponsive after em* UP.  I rechecked for updates, but it reports being up-to-date.

Last time I updated (to 16.7.5) I think I did it via the serial console, so I can sort-of confirm that it worked then.

I can dismiss the first box-dead-after-reboot as a one-time post-upgrade thing, but this serial console issue doesn't want to self-heal so nicely.  Any advice?

I've been reading in the 16.7 forum how the original Intel driver is solving some problems for people who have been using the standard FreeBSD driver.  Would the "pkg install intel-em-kmod" fix also install on an A10 QC running 16.1.20?

I updated a box with PPPoE WAN connections to the 16.1.18 from .14 or so, and noticed the new Traffic Graph re-work for the first time.  The PPPoE interfaces are not included in the graphs, although they are listed in the drop-down box underneath.  The statically assigned or DHCP assigned interfaces are included.

Is this a bug, or something odd in my config, or is there something I am supposed do to get them to appear in the graph?  On the other side of the coin, there are some interfaces I have no need to view (e.g. IPSec) and would like them to exclude them.  Generally, do I have any control over what appears in the Traffic Graphs?

My opnsense 16.1 router has exhibited two problems in recent weeks, neither of which appeared during several months of use with 15.7.  Both seem related to the fact that my internet links are via PPPoE.

The connection down problem is pretty severe and my only solution so far is to reboot:

One of my PPPoE connections will go down.  OPNsense will try to reconnect but timeout after 9 seconds and retry, over and over and over, thousands of times, probably forever if I don't intervene.  My first thought was that something upstream had failed, but this has happened several times now and I've had some opportunities to fiddle around during breakage.

If I move the "connection down" cable from the OPNsense to a laptop and configure the same PPPoE connection it comes right up.  I can also move that cable to the router I used prior to deploying OPNsense and it will also bring the same PPPoE connection up.  But even moving the cable back to the OPNsense at this point, it will only retry retry retry.  Rebooting the OPNsense clears it's head however, and it can then successfully bring up the PPPoE connection as if nothing was ever wrong.

The symptoms sound the same as https://forum.opnsense.org/index.php?topic=2337.0 but that thread seems to show that the problem was resolved with 16.1.5.  I started the 16.1 series from 16.1.7.  There's some mention of RFC 4638 support having been implemented but my PPPoE connection MTU config in OPNsense is the ISP-recommended 1454, and should have nothing whatsoever to do with any RFC 4638 code.  No VLANs are used, the OPNsense is cabled directly to the ISP equipment.

Any help appreciated.  What other info could I provide that would help you help me?

My opnsense 16.1 router has exhibited two problems in recent weeks, neither of which appeared during several months of use with 15.7.  Both seem related to the fact that my internet links are via PPPoE.

The apinger problem is mostly an annoyance, and I have a work-around:

After booting up, the apinger service has failed to start, and my gateway statuses only show "Pending..." forever.  Looking at the gateways.log shows e.g.
Apr 18 08:51:55 OPNsense apinger: Starting Alarm Pinger, apinger(6114)
Apr 18 08:51:55 OPNsense apinger: No usable targets found, exiting

I'm guessing the PPPoE connections haven't been made yet, so apinger figures there's nothing to do.  By the time I log into the web gui moments later, however, the PPPoE connections have come up, the IP addresses are shown in the Dashboard etc, and traffic is flowing nicely.  But apinger never seems to try again, I've tried waiting for hours.  My workaround is to log into the web gui and hit the Start Service button on the Gateways page.  Is there something I can do to fix this?  Either have apinger not bail out so fast, or retry again periodically, or something?