Messages

Back then I think what fetch needed was a limit to the retries to escape the vicious cycle, but such an option doesn't exist. I trade a ticket for investigating if that would make sense: then we could re-introduce -a but limit it to e.g. 2-3 retries max.


Cheers,
Franco

Network loop between WAN and LAN?

Nice work indeed.  Eventually we'll have to discuss removing older plugins (especially where upstream isn't pushing out new versions).


Thanks,
Franco

Note: you only need the legacy plugin if you do a manual rule by rule migration.


Cheers,
Franco

Yes, moving the mirror closer should help.


Cheers,
Franco

So -a has a history for us: https://github.com/opnsense/update/issues/90

I also don't quite get what's happening here:

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

It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok?  Why doesn't it work the first time? This isn't a client-side riddle IMO.


Cheers,
Franco

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


Cheers,
Franco

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

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

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

Supporting nosync would be as easy as https://github.com/opnsense/core/commit/8f8a4c8c35d actually.

But it would be best to add a ticket so we have the request and use case on file on GitHub for future reference.


Thanks,
Franco

FWIW, I read the thread again and the discussion is very technical and fruitful on the first page. The second page leaves some suspense of judgement to be desired, but it also points out the problems people have with the approach the project takes. The question is how to position yourself to something that you can't really put to the test as a whole, but appears to show in great detail how it will change the world. Usually, in open source, you'd find the opposite to be true and much easier to verify. The opposite approach resembles marketing like a commercial product would.


Cheers,
Franco

I agree with your assessment about bad apples, but I don't see it here in the way you describe.  A separate forum post may have been more effective for you to make your point.

There's reasonable doubt about AI use and vibe coding.  We don't see the source code yet -- it's even suggested the source code may not be open sourced.  We saw a lot of hype and news and teasers but no substance yet.  There's a lot of valid scepticism.  That's basically the whole situation.

If it succeeds it will be good.



Cheers,
Franco

@bob9999 I'm not really understanding where you add more value to this discussion. If your aim was to disrespect some people on this forum (or in this thread) you've likely succeeded.

Was this regressing in a particular 26.7.x version or already the case in the initial 26.7?


Cheers,
Franco