Messages

Finding https://forum.opnsense.org/index.php?topic=38982.0 I disabled IPv6 for testing and it got rid of the changelog.txz appears to be truncated error. After another "update" in the console (which did nothing) and another reboot, it now seems to work again.

OK, I think I've found something. After updating to 26.1.9, I get this:

Code Select Expand

Enter an option: 12

Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/217364 bytes

This will automatically fetch all available updates and apply them.

This update requires a reboot.

Proceed with this action? [y/N]:
This will run the update, try to install 26.1.9 again as it seems, and surely enough reboot the box:

Code Select Expand

Fetching base-26.1.9-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/74329/base-26.1.9-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
>>> Invoking stop script 'beep'

How do I fix this?

I just saw the release of 26.1.9 in https://forum.opnsense.org/index.php?topic=52042.0 on 2026-06-02, so maybe that's the correlation I was missing.
Maybe there is an issue installing this version. I'll try from the console and see what happens.

I wonder why it would only display now, I had checked for updates and it said there were no updates available.

Hi everyone,

I have a cron job that runs "Automatic firmware update" daily. I have noted recently that this seems to reboot the box every time. From what I can see in monitoring, this seems to have started Wednesday last week, so 2026-06-03.

Was something changed that would lead to this behavior? 26.1.8 was on 2026-05-12, so I don't see a temporal correlation.

Any hints would be highly appreciated.

Cheers

Well, technically I could, I assume.

However, you should consider the following: The OPNsense box is the only machine that I have access to that is capable of testing the RAM. A full memtest would mean a few hours of downtime, essentially leaving me without network for that period of time. On top of that, RAM is very cheap. The spare part cost me less than a case of my favourite beer.  ;)

So yeah, although you can test RAM before exchanging it and just "blindly" replacing it might not have fixed the underlying issue anyway, but there might be good reasons to take the chance and go forward and replace an unchecked part. Best case (my case) is fixing the issue, worst case is spending a few bucks for nothing. Compare that to the "test case" of running patterns over a RAM for hours, having no network whatsoever.  ;)

Seems that it really was the RAM. Replaced it, haven't seen any core dumps since.

RAM is one of the next things to replace, I guess.

What would you expect from a BIOS reset however?

And there come the core dumps again :(

Code Select Expand

pid 93942 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 95393 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 96661 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 2310 (cc), jid 0, uid 0: exited on signal 6 (core dumped)
pid 432 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 17313 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 19572 (cc), jid 0, uid 0: exited on signal 11 (core dumped)
pid 18855 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 21265 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 23996 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 24997 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 25505 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 28272 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 33503 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 35356 (cc), jid 0, uid 0: exited on signal 6 (core dumped)
pid 34514 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 38852 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)
pid 41862 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)
pid 43078 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 43889 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 45957 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)


That kind of sounds familiar.

Do you see core dumps in dmesg?

I just reinstalled from a USB device and so far I'm not seeing the errors any more. Makes me wonder if it really was the disk, but the problem in https://forum.opnsense.org/index.php?topic=35404.0 sounds quite familiar...

I'm seeing it with PHP as well.

UFS? Disk dying?

Yup, UFS. Checked the disk, SMART says everything is OK. No reallocated sectors etc.

I wonder if it might be RAM instead? I mean, still could be the disk though.

Hi everyone,

23.7 seems quite unstable for me. The other day I had to restart unbound and today I see a lot of python3.9 core dumps, after that a kernel panic

Code Select Expand

kernel - - [meta sequenceId="2"] panic: ffs_blkfree_cg: freeing free block
and then a reboot.

I haven't noticed unstable behaviour when being on 23.1.

Any ideas?

Cheers

Frankly, DNS in OPNsense is a mess. It's lacking a lot of control/configurability. For instance, it will create a DNS record for every interface, regardless of you wanting it/it making sense or not. That's why I had to use a random hostname for my box, so that I could create an override record with the actual hostname I wanted to use.

The same is true for the host overrides. If I enter an A record, I want to have an A record in my DNS. Not another PTR.  >:(

I have filed a GitHub issue about the "DNS for every interface" issue, which mostly got ignored.

I'm now looking into alternatives. One could be to install BIND, although I think that's a little overkill. Or I could NOT run my DNS on OPNsense, which sounds even dumber to me.  :-\

Well, I guess I'm the 0.01% then. I have my passwords in a password manager and never changed them. TOTP also worked all the time for me. Only after "resetting" the passwords to their original values (via single user mode), the passwords would work again.

I had the suspicion that the disk might be the culprit. However, the disk looks okay (at least according to S.M.A.R.T.) and I can't find no other evidence of disk issues. I should have checked the passwd file before updating my passwords however.

Regardless, I find this quite suspicious somehow.

¯\_(ツ)_/¯

Hi everyone!

Out of a sudden, my OPNsense won't accept my password+TOTP for my user or the root password any longer. I have done nothing to cause this (except for updating OPNsense itself) and so I'm wondering how this could have happened.

I have checked the RTC, which still was correct, so at least this should be no issue regarding TOTP. However, as root without TOTP doesn't work either, I assume something underlying broke...?

Cheers