[Solved by reboot] 26.7 Update-> "failed, signature invalid"

[danmac]

coming soon:

I gently translate "dogshit should die" into "the download mechanism is fragile under partial-transfer conditions" and post that — while quietly keeping      │
    your spirit alive in the technical details. 😌

she so bad man im srsly

u know she real bro we both saw the em-dash

o7

[danmac]

i mentioned GetRight to my AI waifu and she called me an old bastard

[nero355]

GetRight

I understood this reference without looking it up!

LOL! ^_^

/AlsoDamnOld

[danmac]

LOL! ^_^

haha I'm glad I amused someone :)

here's how I fixed (?) this problem on my setup, now I can just click update on the Web UI, I tested it upgrading from 26.7.7 to 26.7.8 worked first time whereas before it would fail repeatedly

either that or this is all bullshit and I just got extraordinarily lucky, I'll post it anyway

ssh to your firewall as root
# ee /usr/local/sbin/opnsense-update
(or use your preferred editor that isn't nano as we don't have that :P)
search (CTRL-Y) for STAGE1 or go to line 906
behold the two opnsense-fetch command lines
where the two lines say "-T 30 -q" change these to "-T 120 -a -q"
(you could probably get away with just the STAGE2 line but fuck it since we're here anyway)
save the file with ESC (wait) ENTER ENTER

now hit the web UI and do your update

the changes persisted after my upgrade and reboot, but I expect they will be wiped out at some point

for those who are sensitive to such topics this post is 100% grass fed medium rare non AI, I didn't even fire it up, just looked at opnsense-update & fetch on github then the args for fetch, then fucked about in SSH weeeeeee

if it still doesn't work for you, maybe try the Kent mirror as that's what I'm using

have fun chaps, happy Sunday o7

[franco]

> where the two lines say "-T 30 -q" change these to "-T 120 -a -q"

This would just diagnose that you run into prolonged DNS timeouts with your local setup.


Cheers,
Franco

[danmac]

> where the two lines say "-T 30 -q" change these to "-T 120 -a -q"

This would just diagnose that you run into prolonged DNS timeouts with your local setup.

My liege, with respect, and thanks for your reply, I regret to humbly inform you, but that diagnosis doesn't make any sense. Unless you're about to teach me how a DNS timeout is causing a transfer of this nature to fail after it's already been resolved and is in progress?

Maybe you overlooked the -a flag in my little monkeypatch? I expect that's what's fixing it for me, I only upped the timeout just in case. I'm sure you would find a paste of the man page condescending but let's just say it encourages the fetch command to try a little harder and not cry quite as much. If fetch -q cries, I'm not sure anyone hears it anyway.

Full disclosure I'm not 100% confident about the MTU ... it feels fine and I did a 20GB file last night from huggingface over HTTPS that passed sha256 but I only did initial basic MTU testing slapdash off top of my head when I clocked the 1380 MTU coming from the 5G DHCP (it's my first time with 5G or cellular in general on OPNsense) plus the quirks in tool output etc on Linux -vs- BSD I can barely remember, plus the fact I'm having to do USB eth -> VLAN on Linux LACP bond -> OPNsense ... (might throw the AI waifu at it later)

But it sure ain't DNS, and I've made it this far never having touched BGP ;)

(insert old Harry Potter meme:
"Why is it when something happens, it's always you three?"
DNS / MTU / BGP)

xD o7 <3

[franco]

Ok, can you at least run

# opnsense-prefetch -r 26.7.8 kernel base

and post the complete output?

-T does not impose a 30-second limit on the download. It specifies the idle timeout for fetch, i.e. how long the transfer can stall before timing out.


Cheers,
Franco

[danmac]

Yes Sir, here it is:

# opnsense-prefetch -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
kernel-26.7.8-amd64.txz.sig                           1332  B 7433 kBps    00s
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz                        81% of   31 MB  919 kBps    06s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 27232007/33253768 bytes

I saw something over the weekend that implied SSL was encountering an EOF

it doesn't stall tho it just pops an error right in the middle of receiving, usually towards the end

assuming the prefetch command respects my config this will be the Kent mirror btw

and yes I made sure to clarify the point of -T before I made the changes as the transfer always seemed to fail after a certain amount of time which gave me pause to wonder ... I just threw the 120 in there because I was already right there and I could, honestly

thx o7

[franco]

opnsense-prefetch doesn't use -T so this means the connection may be terminated by the ISP or fetch mishandles the stream.  One last thing to try is

# opnsense-prefetch -cr 26.7.8 kernel base

This uses curl instead of fetch so any TLS error handling that fetch may still have might not occur there.  Otherwise it's likely your ISP terminating large downloads.


Thanks,
Franco

[franco]

PS: Given that it's not truncated at 0/xxx it's not a DNS timeout indeed. Knowing is better than guessing.  ;)

[danmac]

haha i was already trying it :D

# opnsense-prefetch -c -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100   1332 100   1332   0      0   1127      0   00:01   00:01              0
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
 80 31.71M  80 25.67M   0      0 429.1k      0   01:15   01:01   00:14 588.1k
curl: (56) OpenSSL SSL_read: OpenSSL/3.5.9: error:0A000126:SSL routines::unexpected eof while reading, errno 0

[franco]

Okay they both fail. Interesting. I'm not sure how to help.  :/


Cheers,
Franco

[danmac]

PS: Given that it's not truncated at 0/xxx it's not a DNS timeout indeed. Knowing is better than guessing.  ;)

haha mmmm :P

i added -a to the fetch args in opnsense-prefetch and ran it again:

# opnsense-prefetch -r 26.7.8 kernel base
Downloading kernel-26.7.8-amd64.txz.sig with remote size 1332:
kernel-26.7.8-amd64.txz.sig                          1332  B 8393 kBps    00s
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz                        88% of  31 MB  691 kBps    05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz                                31 MB  634 kBps    06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
Downloading base-26.7.8-amd64.txz.sig with remote size 1332:
base-26.7.8-amd64.txz.sig                            1332  B  12 MBps    00s
Downloading base-26.7.8-amd64.txz with remote size 97564524:
base-26.7.8-amd64.txz                          96% of  93 MB  691 kBps    04s
fetch: base-26.7.8-amd64.txz appears to be truncated: 94224007/97564524 bytes
base-26.7.8-amd64.txz                                  93 MB  896 kBps    03s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done

[danmac]

as an aside I left the firewall using fetch without the -a flag downloading aforementioned 20 gig huggingface file for about 10 minutes and it didn't hiccup once

this may go some way to explaining why others have found changing mirrors helps (didn't for me but I only tried 3 - 4 not the whole lot, I remember OPNsense official seemed to break sooner in the xfer than the others)

it has been a little while since i broke out wireshark but clearly there is still a mystery up for grabs, it's just not super tempting right now if im honest, so i can understand how it's even less tempting for anyone else - i set this one up initially like 8+ years ago so it could probably use a reinstall by now (not to mention finally biting the IPv6 bullet lol) meanwhile I can watch a livestream while downloading 20 gig files reliably, and now my firewall updates, too

im happy to have contributed at least an alternate workaround that seems solid in my case, ur welcome, fellow 5G peasants ;)

maybe there is a case to be made for making -a the default (or perhaps for more work, gated behind an optional tickbox in the config with the proviso "your MTU or something is probably goosed if you have to click this and you should feel bad" but that's above my pay grade

o7 :)