ioc update is confusing

[urosgruber]

I'm not sure this even works but last time I tried it didn't. Checking wiki page I see the idea is to use ioc exec foo freebsd-update. Would it be better to then remove the command?

While on this topic. What is the best way to do an upgrade from 11.x to 12.x?

Hmm, noticed this after trying via exec

src component not installed, skipped
Updates cannot be installed when the system securelevel
is greater than zero.

[gronke]

While on this topic. What is the best way to do an upgrade from 11.x to 12.x?

.. I have to go 🙈

This is a challenging question, because I have no finite answer. Let's start digging into the issue by looking at regular updates of a release. (I will leave out HardenedBSD here for the moment, hoping not to upset @lattera. In fact updates on HardenedBSD are easier, which is why I find it fair to focus on issues with FreeBSD updates).

freebsd-update.sh fetches differential updates, but we're only keeping one dataset for release updates of each major version, forcing us to update to the latest patchlevel. This is untrue when using basejails (which is the default), because they mount updates release assets into the jail that can be of any patch level that a host has available. The only way to make such a patchlevel available is by using Release.fetch() while it is the latest available target. It is not possible to create a release with patch level p2 when p3 (or newer) are available. Due to the constraint of one update dataset per release (e.g. /ioc/pkg/<major_version>/), we do always fetch updates as if we would update from the unpatched releng release. This way we ensure that all targets reading that updates dataset can be updated to the latest patches (which is more important when using non-basejails).

The lazy way of keeping a jail updates is to not pin a release patch level (e.g. ioc set release=12.0-RELEASE-p1), but to leave it undefined, so that it always points to the latest available. (e.g. ioc set release=12.0-RELEASE without patchlevel). When a jail is now stopped and started, the mountpoints will point to whatever is latest at the time of starting. With luck it is not required to run mergemaster.

What's the problem with mergemaster? Well, it is an interactive process. Although it does not always read user input, it still could wait for input at any time. Because libioc is a non-interactive library, we would have to automate the users input decision or would require an entire channel back to a human. Lame!

Now upgrading a distribution opens another can of worms. We would have to know from which release we want to upgrade to another. This would imply that release updates would have to be fetched from any older release on a host to any newer. I neither find it acceptable while fetching updates for one release, not do I like the idea of doing it when attempting to apply an upgrade to a jail.

Also upgrading a jail to a newer release, would make it depend on both. It depends on the old release because it is the ZFS clone origin of the jail root dataset, which only goes away by re-creating a jail from another release. It also would depend on the new release, because it would get the mountpoints from there. Having all jails updated to a newer release, but have them still depend on another, unreleated release seems very unfortunate and hard to explain when attempting to delete a release that no more jail points to.

Personally I use the import/export feature to create a differential update of the jail content against its release. The archive creation or extraction can be omitted, so that the process can be more efficient than manually using the full export and re-import. The publicly available code does not yet support this and also lacks the ability to override config properties on import.

Failing on this seems super evil to me, because often a broken jail is noticed too late. I would be super happy about feedback regarding the export/import feature. If no breakage is reported, I'd feel more confident to publish a migration path that decouples a jail from its release and re-creates.

Running mergemaster in the "new" jail is still required by the way, and of course is an interactive progress. So you won't get around doing some manual work. @kmoore134 told me he is working on a solution for non-interactive upgrades, but until that is available, there is no way around user interaction.

I emphasize users to use provisioning instead, so that jails can be re-created from scratch at any time. Using another jail that is frequently provisioned as template for workers turned out to be less pain than juggling with individual jails in production.

[lattera]

I'M SO UPSET! (Just kidding!)

Even updates to a release branch may impact mergemaster or etcupdate. Both FreeBSD and HardenedBSD have that same problem, HardenedBSD even more so since we're a rolling release based on the stable branches.

The difference is that HardenedBSD uses etcupdate and FreeBSD uses mergemaster. Neither are friendly to automation, and I'm even suspicious of the etcupdate integration work I did with hbsd-update, since etcupdate wasn't meant to be run in any sort of programmatic way.

[urosgruber]

I'm also doing provisioning and don't even use update. Didn't try import/export yet, but seems a nice feature to kinda store prebuilt images that can be used during new jail creation.

Would be nice to hear how others are using this command and if not used many maybe removing would be good option.

[gronke]

CBSD

Update of configuration files in jail, etcupdate/mergemaster
To be continued

https://www.bsdstore.ru/de/11.1/wf_jupgrade_ssi.html#jail_etcupdate

iocage

• The string mergemaster does not appear in the entire repository

ezjail

• Runs freebsd-update with PAGER=cat https://erdgeist.org/gitweb/ezjail/tree/ezjail-admin?id=b418a79584b08ede5b665fc859fb6f3a01a4b044#n1027
• Requires manual execution of mergemaster https://www.freebsd.org/doc/handbook/jails-ezjail.html#jails-ezjail-update-os

---

Unattended upgrades appear to be an unsolved problem in the jail manager world.

Although I recommend provisioning jails with the controller of choice in automated environments, there is good reason to use ioc to maintain persistent jails. After a jail (or its basejail release) were updated, it is recommended to manually run mergemaster or etcupdate in the affected jail.

When upgrading to a newer release, I believe our best bet is to allow the importer to override config properties, so that the jail is created from the new release. For example:

ioc export my-old-jail /tmp/my-old-jail.txz
ioc import my-new-jail /tmp/my-old-jail.txz -o release=12.0-RELEASE 

[lattera]

FWIW, last year, I opened a help wanted feature request in HardenedBSD's issue tracker: https://github.com/HardenedBSD/hardenedBSD/issues/317

Perhaps this would be a good time to collaborate on a solution that would fit both FreeBSD's and HardenedBSD's use cases. :)