File truncated, kernel/base version mismatch

[Tearlach]

Unsophisticated user here.  Just realized I have a couple of issues I ned to get my head around.
Note the highlighted issues below.  Any advice from the more knowledgeable would be deeply appreciated.

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.11_10 (amd64) at Tue Jul 21 10:01:14 EDT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/93517/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
***DONE***

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_10 (amd64) at Tue Jul 21 10:06:04 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-isc-dhcp 1.0_6
os-nut 1.9_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_10 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

[franco]

DNS broken/slow or IPv6 not working as expected on the box.

The 0/1332 bytes means it hit a hard timeout before it could fetch any data.


Cheers,
Franco

[Tearlach]

Thank you for the explanation, franco; I can't imagine I would have figured that out on my own.

My OPNsense platform is a VPN client, with 2 tunnels.  I force most of my traffic out the tunnels, including not only client DNS queries but system DNS queries; the target is an ad/malware-blocking DNS server offered by the VPN provider.  When I have time to reconfigure, I'll change the system DNS queries back to a public server, exiting via the WAN interface rather than the VPN, and see if that clears the issues up.

Thanks again.

[Tearlach]

Franco, I changed the system DNS queries from being forced down the VPN tunnels to using the WAN interface (Quad9 DNS over TLS).  Lookups tested from clients and Interfaces -> Diagnostics -> DNS Lookup appear to function fine.  Attempted updates again:

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 12:31:30 EDT 2026
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/232496 bytes
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 933 packages processed.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.

After a LONG pause, with "Updates" tab showing rotating circle, I am presented with the option to install base 26.1.11 and kernel 26.1.11; current version of both packages is listed as 26.1.7, which "seems" incorrect, as I am running 26.1.11_10 already.  The changelog being truncated is also concerning.  So then I ran System -> Status -> Run an audit -> Health


***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 12:50:25 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-isc-dhcp 1.0_6
os-nut 1.9_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_10 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

OK, so the audit also indicates I'm running base and kernal 26.1.7 vice 26.1.11.  I go back to the "Updates" tab and click on the Update box to install base 26.1.11 and kernel 26.1.11. Note says "There are 2 updates available, total download size is 168.5MiB. This update requires a reboot." Result:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 13:04:33 EDT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/5484/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
***DONE***

I'm stuck. No option to upgrade to 26.7, and my 26.1 software appears to have a problem. As best I can tell, DNS is functioning as expected.  Franco, you mentioned IPv6 also.  Is there anything specific I can check or diagnostic to run to try to narrow the problem down?

[newsense]

Which mirror are you on? Try changing it

To update the kernel and base packages do this:

Code Select Expand

opnsense-update -bkr 26.1.11

[Tearlach]

newsense:

I tried both.  Changing the mirror to one much closer to me reproduced the same exact errors. I then SSH'd to the box and issued the opnsense-update -bkr 26.1.11 command.  Same basic error, as shown below:

root@OPNsense:/home/<redacted> # opnsense-update -bkr 26.1.11
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/48626/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found

[newsense]

Then the DNS and/or IPv6 is still unresolved

[Tearlach]

newsense, Franco:

Any suggestions as to how to troubleshoot "IPv6 not working as expected"?

Thanks

[newsense]

First disable IPv6 on wan and try to complete the upgrade

Everything else's secondary

[drosophila]

You may be having an MTU / MSS issue. IPv6 doesn't have working PMTU discovery yet, but it's header is longer than the IPv4 one, which needs to be accounted for. IPv6 also cannot fragment packets mid-flight, which further complicates things. Intermediate routers may have arbitrarily low MTUs, down to 1200 IIRC, which is much less than the usual 1400+ of IPv4. Add to this the tunnel and you are going down a lot. You can try hard-setting some low MTU size like, say, 800, on the WAN interface and see if things start working then. If so, you can gradually increase it until you hit "your" personal MTU max. This, however, is best tested with leaving the MTU on WAN at default values and instead using, on the command line, "ping6 -s 800 www.google.com" (where the 800 is the packet size to be tested; you'll likely arrive at something around 1180, so you can choose your increments accordingly). Note the "6" in "ping6" since without it, you use IPv4 and thus invalidate the result.