Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - robled

#1
Thank you.  I wouldn't have been able to find the issue without knowing about the CTRL+T trick.
#2
I don't recall the -delete arg taking nearly as long as it took for my system to try and boot (tens of minutes).

I had set my session timeout in the UI to 43830 minutes.  That may have contributed to this.  Perhaps there could be an upper limit in the UI that is below that value to prevent boot issues?
#3
I looked more closely at the most recent log message and found that there are over 200k files in /var/lib/php/sessions:

find /var/lib/php/sessions -type f | wc -l
  277237

Deleting them solves the problem with the importer script:

find /var/lib/php/sessions -type f -delete
The issues with monit and unbound seem unrelated.  I'll look into filing a bug report upstream tomorrow.
#5
After upgrading from 26.1.2_5 to 26.1.3 my system hangs after reboot at >>> Invoking import script 'importer'
I tried booting into my previous boot environment, and got the same error, so there was no recovery with that.  Eventually I just pressed CTRL+C at the >>> Invoking import script 'importer' log message, and then, unexpectedly, the boot process proceeded past that, seemingly with no error (see screnshots below). 

After the system booted, most things work, except my monit and unbound services won't start.  I found the logs for monit and it won't start due to a syntax error in the config:

/usr/local/etc/monitrc:39: syntax error 'httpscheck'
monit exiting due to parsing errors in the configuration file.

And for unbound:

unbound-checkconf /var/unbound/unbound.conf
[1773169580] unbound-checkconf[19639:0] error: pythonmod: can't open file unbound-dnsbl/dnsbl_module.py for reading
[1773169580] unbound-checkconf[19639:0] fatal error: bad config during init for python module

I haven't been able to determine what the importer script does.  Something to do with loading or upgrading the config file?  Perhaps my monit service is failing because it wasn't able to make necessary changes for new syntax?

I also ran into this problem once with a different set of hardware, and wound up replacing the hardware due to unrelated changes I needed to make, so I don't think it's an issue with my hardware.  zpool status, dmesg, and memtest are clean.

Searching around I've not seen others with this issue, so it's definitely perplexing.  Certainly I need to figure out why my monit and unbound services aren't working, and prevent this from happening during the next upgrade.  Also, post-upgrade if I reboot I still have to CTRL+C out of the importer script.



#6
26.1 Series / Re: Lost my IPv6 prefix
January 31, 2026, 08:48:34 PM
After waiting a day and not changing my config, my prefix just showed up again.  Not sure what changed, but please ignore me and carry on.
#7
26.1 Series / Lost my IPv6 prefix
January 31, 2026, 02:19:59 AM
After upgrading to 26.1 I lost my IPv6 prefix.  My ISP is Google Fiber, and they generally do IPv6 the right way, with DHCPv6 PD, and give out a /56 prefix.  Worked fine with previous OPNSense versions.  With tcpdump I can see some DHCPv6 activity:

16:46:46.740180 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:46:46.742118 IP6 fe80::1.547 > fe80::3eec:efff:fe27:ea7e.546: dhcp6 advertise
16:46:47.740534 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 request
16:46:47.742462 IP6 fe80::1.547 > fe80::3eec:efff:fe27:ea7e.546: dhcp6 reply
16:46:57.892093 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:46:58.970018 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:47:01.022492 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:47:04.989532 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:47:13.057771 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:47:28.683178 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit
16:48:01.233762 IP6 fe80::3eec:efff:fe27:ea7e.546 > ff02::1:2.547: dhcp6 solicit

I know there are a lot of changes with regards to IPv6 in this release.  I began clicking around with the new options, trying out various permutations, like Identity Assocation and Track Interface (legacy).  But it seems that things never progress that far, because my WAN interface never seems to get a IPv6 address or a prefix to delegate to the LAN interfaces.   I did convert my firewall rules to the new format and deleted the legacy rules.  Just to see if the new firewall config was causing issues I added a rule to allow inbound UDP 546 with no effect.

I'm posting some screenshots of my current config.  Will be happy to provide more info and file a bug report if necessary once I learn more about what's going on.  Thank you.