Messages

I believe the iflib.driver_version is returning the same value formerly appended to the %desc value.

https://www.freebsd.org/cgi/man.cgi?query=iflib&manpath=FreeBSD+12.2-RELEASE
The Description paragraph of the iflib man page explains how its purpose is to allow driver authors to use a standard set of sysctl names, and defines driver_version as "A string indicating the internal version of the driver."  I take "the driver" to mean "the driver you wrote to operate the hardware" not "the iflib framework".

https://www.freebsd.org/cgi/man.cgi?query=em&sektion=4&manpath=FreeBSD+12.2-RELEASE
The value returned by my i350 dual-port NIC is in line with what madj42 linked to.  The History paragraph of the em man page explains how "em was merged with the igb device driver and converted to the iflib framework in FreeBSD 12.0."  Which would explain why the unused Intel igb driver version does not match the one from the kernel reported via iflib.driver_version.

I think the info you're after is now in the 'iflib.driver_version' component instead of '%desc'.

# sysctl -a | grep -E 'dev.(igb|ix|em).*.iflib.driver_version:'
dev.igb.1.iflib.driver_version: 7.6.1-k
dev.igb.0.iflib.driver_version: 7.6.1-k

Haven't done it myself but this thread from when RFC 4638 support was added to OPNsense should give you something to try:  https://forum.opnsense.org/index.php?topic=2238.0

If you're wanting a "Yes, I've done that" reply, here it is.  I have a number of FreeBSD servers with LACP uplinks to switches, including one that is a 4-port 1GbE LACP trunk to a Cisco 3850 switch.

The only issue I have with that one isn't related to the link aggregation, but to a bug with VLAN tagging in hardware, which is broken if you are bridging VLANs.  This is scenario more likely to happen when the host is running virtualized guests.  Less likely if you're just routing/firewalling.

I've never had to do this with my OPNsense systems as none of them even have video output.  On a FreeBSD system it's just a matter of loading the green_saver kernel module, which is included in OPNsense.  Maybe somebody knows if this can be done via the OPNsense GUI?

If you're not afraid of the console, open a shell as root and type 'kldload green_saver'.  I think the default is 5 minutes of no keyboard/mouse activity, or you can hit Shift-Pause to activate immediately.

Now I see what you mean.

The help text for each of the five time & date fields is essentially the same and sufficient for most cases.  But where most people can probably map "July" to "7", it is not so obvious that "Wednesday" is "3", and you're asking if someone could improve the help text for "Days of the week" to include this non-obvious mapping.  Or at least hint that words like "wed" or "thu" could be used instead.  Uncertainty about the mapping for users who aren't so familiar with cron and from users (like yourself) who are familiar enough to wonder if the GUI might have it's own user-friendly-and-different expectation of input.

Would you propose something like:
"Enter the days of the week for the job to act, can also be a comma-separated list, * (each) or a range (ex. 1,2,3 or 1-3) where 0 or 7 is Sun"

Or some static text at the top of the entire form saying something like:
"The settings you save here will be added directly to your crontab file.  For details, see 'man 5 crontab'."

Or something else?

When I first configure a cron job on a server, I usually also paste in these explanatory lines from 'man 5 crontab'.  Prefixed with #'s so they are just comments to cron, the result is this:

Code Select Expand

# field         allowed values
# -----         --------------
# minute        0-59
# hour          0-23
# day of month  1-31
# month         1-12 (or names, see below)
# day of week   0-7 (0 or 7 is Sun, or use names)


There's more info in the man page (of course... that's why it's a man page), but the above bit is enough to remind me of the number, order, and meaning of the time and date fields.  Having it right there in the crontab also means it's viewable whether you're editing cron jobs in the GUI or CLI.

I'm curious which image you downloaded & installed?  vga?  serial?  Odd that it fails only on first cold boot.

With most things Mac, an NVRAM reset would be someone's first advice, or even SMC reset.  But I wonder what that would do now that you don't have MacOS booting to repopulate those settings.

You've hit everything I would have thought to try.  For me, your #8 has usually been the one that gets it working... puzzled that didn't solve it for you.  Might be something about the Nano image.  Is there a reason you're using the Nano image instead of a regular VGA or Serial image?  Maybe somebody else spots something you've missed.

Probably not much help, but I use Etcher (https://www.balena.io/etcher/) to write the images to media.

Nothing wrong with your plan, and kudos for having a plan!  My cold spare plan is slightly different, but it works for me because maybe my configs don't change as often as yours.

My cold unit is configured exactly like the live unit, same OPNsense version and configuration file.  Then powered off and left that way.  If/When the live unit blows up, I or anybody else can simply swap the cables and power on the cold unit to get things working again.  The cable swapping person doesn't need to know how to log in and upload a configuration backup.  Once internet has been restored, the cold-now-live unit can have its' OPNsense updated and a more recent config imported, if necessary, after working hours when it won't affect anybody.

Also, when major updates are due, e.g. 19.1.x to 19.7.x,  I usually do a fresh install on the cold unit then switch over to it as the live unit and leave the live-now-cold unit alone in case something is found totally broken on the new version.  Swap the cables back and I've reverted to a known working unit.

While I agree that box is overkill, if you got it free from work you've already saved the costs of any electricity bill hike for quite a while.  The noise may or may not be a factor for you.

How about this idea:  install your hypervisor of choice on that box, and run OPNsense plus other projects as VMs on it.

From this post https://forum.opnsense.org/index.php?topic=9678, titled "16.1 and 16.7 update sets have been removed", I think you cannot upgrade a 16.7 system via the internal upgrade mechanisms.

As for the hanging during cpdup, my own anecdote:  zero out the beginning and end of the disk (to wipe out any GPT stuff) and partition as MBR.  That worked for my appliance, but may have nothing to do with your situation.

My only other thought is to maybe try a fresh 19.1, 18.7, or 18.1 install.  If you can get one of those working, then upgrade to 19.7 from that.

The tmpfs driver is only an in-memory filesystem, i.e. RAM disk.  If RAM gets low the kernel *may* write out parts of your RAM disk to the swap file (if you have one), but nobody would consider that a "backup".

The md (memory disk) driver provides RAM disks with tmpfs, but also other options like swap-backed or file-backed.  While you could use md to have a RAM disk backed up to a USB key, I don't think that would help your situation.

https://www.freebsd.org/doc/handbook/disks-virtual.html

Not sure what else might be required, but your fstab is still declaring the file systems for /tmp and /var as 'tmpfs' instead of 'ufs'.  You've shown your USB key partitions are formatted ufs.  tmpfs is for in-memory filesystems.

And if this USB key is just flash memory, you may also want to include the 'noatime' option on those partitions to cut down on the number of writes.

I got similar errors, and updating from console just gave me stuff like:

Code Select Expand

Fetching change log information, please wait... fetch: https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/sets/changelog.txz.sig: No route to host

...even though I could do this:

Code Select Expand

root@OPNsense:~ # ping pkg.opnsense.org
PING pkg.opnsense.org (212.32.245.132): 56 data bytes
64 bytes from 212.32.245.132: icmp_seq=0 ttl=47 time=270.799 ms
64 bytes from 212.32.245.132: icmp_seq=1 ttl=47 time=277.514 ms
^C
--- pkg.opnsense.org ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 270.799/274.156/277.514/3.357 ms

So I tried:

Code Select Expand

root@OPNsense:~ # curl https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/sets/changelog.txz.sig
curl: (7) Failed to connect to pkg.opnsense.org port 443: Connection refused

...and figured whatever the problem was, it likely was at the pkg.opnsense.org end.  Could not remember how to change mirrors from console, so went to the GUI, set it to the same mirror I'd just downloaded the 19.1 installer from "LeaseWeb (HTTP, San Fransisco, US)", and clicked the "Check for updates" button.  That worked, and I'm downloading updates right now.