Messages

Found the problem.  Added qat_load=YES to the system years ago.  Apparently it's no longer necessary or somehow is incompatible with FreeBSD 14.  In any case, system is now working fine on the latest version!

Quick little update...

I installed 24.7, updated it to 24.7.12_4 and imported the config file.  No issues.

Updated to 25.1, kernel panic.

So definitely something about 25.1 isn't thrilled with my 24.7 settings.

I have an opnsense box I've been managing for about 5 years.  Supermicro C3758 based system.  I decided that since an upgrade failed long ago, when 25.1 came out I'd do a fresh install and import my config file.  While I was onsite I did a BIOS and IPMI update.  BIOS was factory defaulted and reconfigured appropriately.  System booted up 24.7.14 (whatever the last version was) without issues.

I then decided to install 25.1 which happened without issues.  I then uploaded the config file and first reboot was fine.  However if I reboot again (even if I change nothing) the box kernel panics while booting.

So I reinstalled 25.1 again and updated it to 25.1.3 without problems.  Did a few reboots and no problems.  Then I uploaded my config file and after 2 reboots it kernel paniced again on bootup.

Here's a screenshot of the panic.  Can anyone shed some light on this?  I *really* don't want to have to start over from scratch, it has quite a few VPN links and other things, and if this can give me a direction to go, I'd prefer to go that way before having to start with a clean config.

Note that I hadn't gotten to install any of the plugins yet because I was still in basic testing when I realized this problem.

Okay, so not as easy as doing something from the CLI, but this does work.

First, setup everything in General Settings and Alert Settings.  Under your recipient, make sure the event "Monit instance changed" is checked.  Save and click Apply.  Poof, you'll get an email because that alone will trigger monit to reload itself, and the instance changing will send you an email.

Of course, you can also trigger it anytime now if you keep the "Monit instance changed" setting enabled by simply reloading Monit.

As I'm new to using monit heavily, this took me a long time.  Way too long.

Is there a way to have monit send a test email to make sure everything works properly?  I'm 99% sure monit isn't actually working for me, but I can't figure out how to tell monit to send a test email.

I even tried a service test by creating one with condition 'failed host 127.0.0.1 port 1234', but then after saving it and such, I went to my recipient under alert settings, but I can't even select my test condition.

I was hoping I could just go to the CLI and do something like "monit emailtest" and have an email get sent

Nobody?

Wow.. I didn't think I'd stump the collective sum of knowledge from opnsense!

I'm relatively new to dtrace, but I am convinced this *should* work.  I'm running opnsense 24.7.10_2-amd64 and I'm trying to run this but getting the below error:

Code Select Expand

# dtrace -n 'dtrace:::BEGIN'
dtrace: invalid probe specifier dtrace:::BEGIN: "/usr/lib/dtrace/mbuf.d", line 118: syntax error near "caddr_t"

Running this on a pure FreeBSD system does work.  Am I crazy?  Should this not work?

Ultimately, I'm having performance issues with openvpn, and I'm trying to actually validate that aesni *is* in fact being used.  Also I wanted to see if the kernel module if_ovpn is used.  Just trying to rule out optimizations that aren't being used, etc before I try digging further.

I can verify the modules are loaded, but I'm looking to prove they are actually being used.

Thanks!

And... it's official.  I am stupid.  That worked!  Somehow it never crossed my mind that the checkbox would work that way.  Thank you!

I switch to Kea from ISC for DHCP services.  In ISC it has a very clear field where you can set the DNS server to use.  In my case, I want to use a pihole for one of my networks.  How can I set this?  I looked in the GUI and searched around and either the function doesn't exist in the WebGUI, or I'm stupid and/or blind.

Thanks!

Okay, so I fixed it. I believe the system was all messed up because I had told the interfaces to "prevent interface removal".  Here's what I did:

1.  Uninstalled Zerotier plugin.
2.  Went to the interfaces and unchecked the "prevent interface removal" for each of the zerotier interfaces I had.
3.  Removed the interfaces from the system.
4.  Reinstalled Zerotier plugin.
5.  Reconfigured everything as necessary in the WebGUI.  This included adding the interfaces again, etc.
6.  Went into zerotier's website and added the "new" device to the appropriate network and removed the "old" device from the appropriate network.

I can't remember why I checked 'prevent interface removal' in the first place.  I think there was some odd stuff with zerotier making a new interface on every reboot or every update or something, and instead of having to add my "new" device to the network every time, I simply prevent its removal.

Hello everyone.  So I decided to replace my boot device in opnsense with a mirrored set with ZFS.  I was on the last version of 23.1, and since 23.7 had just come out, I made the choice to go ahead and install 23.7 and then import my config file.  I figured it would be smooth sailing.

Not so much.

Zerotier has been broken since that day.  I haven't had a chance to troubleshoot since it was a low priority, but nwo I need to get it working again.

Looking in the WebGUI of opnsense under the Zerotier section, everything looks normal.

However the zerotier interfaces are not being created.  ifconfig doesn't show them.  I then went to Interfaces -> Assignments and opt7 and opt8 (my two zerotier interfaces) show as "missing" (which I already knew) but I can't get them to be recreated.

I tried uninstalling and reinstall the os-zerotier plugin along with reboots.  I've even installed several of the opnsense updates (along with appropriate reboots) and the interfaces are still not being created.

I also tried creating a new network to see if it would create a new interface.  Still no.  I'm at a loss to know how to either recreate the interfaces that I had or have it create new ones.

I will say that if I log into the Zerotier website to look at device last login, my opnsense box is over 30 days since last login, corresponding with when I did the reinstall.

Any ideas?

Thanks!

@JamesFrisch

Can you provide specs on your opnsense system?  Is it virtualized?

After posting this I noticed the last entry for the OP wasn't a signature but was what he did to fix it.  I tried both US repos, and no change.  I then changed to the DE repo the OP used, and its updating right now.

Sounds like some kind of problem with the repos or something.

I'm having similar issues at both friends' Opnsense systems I manage.  I manage to get mine to update, but it took like an hour.

One friend updated and rebooted as though everything was normal; typical 10-15 minutes for installation and reboot.

The other friend I cannot update despite trying multiple times from the WebGUI and the CLI.  Here's the CLI output from tonight.

Code Select Expand


  0) Logout                              7) Ping host
  1) Assign interfaces                   8) Shell
  2) Set interface IP address            9) pfTop
  3) Reset the root password            10) Firewall log
  4) Reset to factory defaults          11) Reload all services
  5) Power off system                   12) Update from console
  6) Reboot system                      13) Restore a backup

Enter an option: 12

Fetching change log information, please wait... done

This will automatically fetch all available updates and apply them.

load: 0.28  cmd: sh 70400 [wait] 358.96r 0.00u 0.00s 0% 2980k
mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 kern_wait6+0x527 sys_wait4+0x7d amd64_syscall+0x10c fast_syscall_common+0xf8
load: 0.26  cmd: sh 70400 [wait] 361.24r 0.00u 0.00s 0% 2980k
mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 kern_wait6+0x527 sys_wait4+0x7d amd64_syscall+0x10c fast_syscall_common+0xf8
load: 0.36  cmd: sh 70400 [wait] 1318.61r 0.00u 0.00s 0% 2980k
mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 kern_wait6+0x527 sys_wait4+0x7d amd64_syscall+0x10c fast_syscall_common+0xf8
This update requires a reboot.

Proceed with this action? [y/N]: y


Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
pkg-static: https://pkg.opnsense.org/FreeBSD:13:amd64/23.1/latest/packagesite.txz: No route to host
Unable to update repository OPNsense
Error updating repositories!
Starting web GUI...done.
Generating RRD graphs...done.


Note that the part where you see CTRL+T output ultimately took over an hour before I got the "proceed with this action" query.

Clearly, *something* is going on, but I have no idea what.

At this particular location, ipv6 is disabled on the WAN side as there is no ipv6 support. I just tried to do the upgrade from the CLI again, but got a new message:

Code Select Expand


Enter an option: 12

Fetching change log information, please wait... fetch: transfer timed out

This will automatically fetch all available updates and apply them.


This has been frozen with no additional output for probably 30 minutes or so.  I'm hoping this is just a problem with a cdn or something and its an easy fix.

So about 2 minutes after I posted this the system rebooted.  It then took over an hour to do the reboots and install the OS.  Upgrade on first reboot was slow.  Bootups were slow.  Package installs and updates were slow.  I waited it out (very patiently) and it did eventually come up and "just work".

Digging deeper, once opnsense was booted back up and fully functional, my SSD write speeds were around 1MB/sec maximum (nope, that's not a typo).  After some more thinking and analyzing, ZFS property autotrim was set to off.  As I was never running the "zpool trim <poolname>" command from the command line, I assume it needed a trim.  After a zpool trim and waiting a few minutes, I could write at over 100MB/sec.

I've since changed the autotrim property to on with the command "zpool autotrim=on zroot".  Probably would be a good idea for the default to have autotrim set to on.  As a ZFS guru, I will admit that there are situations where autotrim=off may have it's place for some situations and some workloads, I suspect the greater masses would benefit from autotrim being set to on when a zpool is created.

Edit: For anyone that is curious, the total upgrade time from when I first clicked "update" in the WebGUI to the system booted up and functional was almost 2 hours.  LOL.