Solved iocage upgrade of jails

Hello fellow freeBSD community members can you please help?

I am trying to upgrade my iocage jails with the following command

iocage upgrade -r 14.1-RELEASE however I get error messages

1720928781229.png


I am confused on how to update the release inside the jails

1720928833145.png


My host os is

1720928876650.png



However, this version I can no longer use the same IP as the host for the jails so I cannot access the internet with a cloned IP while inside the jails.

Does anyone know how to upgrade the freebsd release inside of the jails without destroying them and spinning up new onews?
 
I know it has to do with my SSL certificate that is self signed for my proxy and firewall I have no idea how to import it into iocage to use it. It will fetch with it off the secure lan.
 
path to most of iocage config is in navigate to cd ~
after cd to
/zroot/iocage

check out the two files

1720936777707.png


1720936799702.png


1720936837111.png



Again, nothing is listed for self signed certificates however after you fetch the image you can set up your jail anyway you like..


Yes it is old but it still works great has some small bugs
 
SoBe
From the output commands it looks like iocage struggles because your jails are unsupported, you've waited too long.
In your situation here is what I would do, save the not working jail as an archive, create a fresh jail and copy back what you need from the old to the new one.
Debugging can be time consuming, do it only if it worth it, it depends on how you value your jail I guess.
But this is just me, may be someone here has a better advice.

sysutils/iocage is indeed in dormant state but sysutils/iocage-devel is well alive and some work have been done to make it shine again, I've been testing it lately and I have nothing bad to say, it works good.
Its Github repo moved to FreeBSD, so hopefully this is a good sign for its future.
If you don't want to change your habits there is a solution at least ;)
 
SoBe
From the output commands it looks like iocage struggles because your jails are unsupported, you've waited too long.
In your situation here is what I would do, save the not working jail as an archive, create a fresh jail and copy back what you need from the old to the new one.
Debugging can be time consuming, do it only if it worth it, it depends on how you value your jail I guess.
But this is just me, may be someone here has a better advice.

sysutils/iocage is indeed in dormant state but sysutils/iocage-devel is well alive and some work have been done to make it shine again, I've been testing it lately and I have nothing bad to say, it works good.
Its Github repo moved to FreeBSD, so hopefully this is a good sign for its future.
If you don't want to change your habits there is a solution at least ;)

That fixed the issues !! Thanks I am on 14.1 with Iocage no issues so far.
 
Happy Bastille Day!!!
After reading so many people stating Bastille was the better option, (even though iocage works just fine) I thought to check it and migrate some hosts. But so far, iocage works better imho. Bastille insists or assume one uses pf firewall. Tried to export/import a vnet iocage jail, but required quite a bit of extra work then stated in the documentation. Noticed on GitHub too people complaining about the pf warnings, make it optional already for a year, but it is still there. So personally not sure if dormant but ready iocage is a less good of a choice compared to what people say active Bastille.


Last actual change, version release is also more then over a year ago.
 
Last actual change, version release is also more then over a year ago.
The last release was in November 2023:
I am not worried about Bastille, it has plenty contributors, the repository is active, commits are there:

I noticed that they do some cleaning from time to time, and do everything at once, one day they close/fix many issues as well as validate (or not) the pull request. The work is done.

Bastille insists or assume one uses pf firewall

I agree, the PF message is not the best thing, it looks like it is hard coded, first time you see that is surprising, but it won't affect IPFW from working.
But I can't really blame the author for making such decision because that is exactly what I observed since I am here on this forum: most FreeBSD users actually use PF, there are few exceptions of course but ... well just reading threads from these sections is self explanatory, you'll barely see IPFW or IPF involved/mentioned in the discussions:
 
Back
Top