27.4.tar.gz not found ...

[franco]

> Because I want to be able to set the FreeBSD base version (13.2/3 or 14.1) and the matching OPNsense version (24.1 or 24.7). Because of the explicit FreeBSD version checks that you have in place that prohibit just fetching from master.

I've avoided stable branches for update tools because backporting deprecated versions is not very elegant and dragging one or two line changes through seems silly enough. FreeBSD EoL versions quickly deteriorate as well as you know.

Most of the noise of update.git is when a new major is released which very briefly breaks expectations for 90% upstream reasons. I'm not sure how I can make it better in the bulk of the issues to be honest. It all works 99,9% of the time in all OPNsense versions it lives in.

Feel free to raise a ticket there and we can see what major pains we can fix maybe.


Cheers,
Franco

[Patrick M. Hausen]

That's dangerous when pkg is a link for whatever reason or a mount point which can't be removed.

Understood. Maybe I don't have the full picture of the intended use of the bootstrap script. I thought its purpose is to turn a stock FreeBSD into an OPNsense once and then never again.

So people can ... like ... install in otherwise inaccessible cloud providers. [1] Or with unusual ZFS pool topologies or whatever.

[1] E.g. boot Linux rescue system, use depenguinator to install FreeBSD, bootstrap OPNsense.

[franco]

The README does note its main use and the additional benefits:

https://github.com/opnsense/update?tab=readme-ov-file#opnsense-bootstrap

You are not wrong. It's simply a lot harder to control FreeBSD itself where we don't ship an opnsense-boostrap port that could be fixed timely (and with the right chain of bug reporting and user exposure).

The script bundled with any OPNsense version should fulfil its expectations without issues (yes there have been a few but not too many over the years).


Cheers,
Franco

[Patrick M. Hausen]

I've avoided stable branches for update tools because backporting deprecated versions is not very elegant and dragging one or two line changes through seems silly enough. FreeBSD EoL versions quickly deteriorate as well as you know.

But if I use master, you cannot bootstrap 24.1 on FreeBSD 13.3 - for example to try to debug some problem in the lab with the version you have in production. Most installations will be running 24.1 for at least a couple of weeks to come. You/we just broke 24.1 in Vagrant for good, if I go that way. And FreeBSD 13.3 is well supported.

I'd love to have the bootstrap script for the betas/rcs, so we would have some amount of overlap here.

How do you guys install early access versions of OPNsense in VMs? We use `vagrant up` for everything. Boot a simulation of our entire data centre with 5 virtual machines? There's a Vagrantfile for that.

[franco]

Well you can use the 24.1 tag to bootstrap FreeBSD 13.3 although it takes that for tolerance of EoL policy and really wanted 13.2 instead. The fun thing is when 24.1 was tagged the pkg-unlock bug didn't exist.


Cheers,
Franco

[Patrick M. Hausen]

Well you can use the 24.1 tag to bootstrap FreeBSD 13.3 although it takes that for tolerance of EoL policy and really wanted 13.2 instead.

Ah ... so master still does support 24.1/13.x? Should have checked the source before posting. Thanks. I just assumed it would now error out with any FreeBSD version but 14.x.

[franco]

The tag can, but HEAD will not. I don't know if GitHub allows easy per file pull of a tag so after thinking it over I'm just going to disable FreeBSD major version check over bootstrap when having fetched the thing without a proper make-based install phase which would adjust the correct value into the script to check:

https://github.com/opnsense/update/commit/faa8226602


Cheers,
Franco

[Patrick M. Hausen]

Perfect! Thanks a lot. My project is updated and pushed, just toying with 24.7 now ...