Ensure iocage update correctly updates the release property with the patch level
I had my sails in 11.2-RELEASE-p2, i wanted to upgrade my jails :
- after an iocage update, my jails are still in 11.2-RELEASE-p2 in GUI
- freebsd-version in jails shows 11.2-RELEASE-p4
after further investigations, it seems that release field in config.json is not updated.
thanks in advance
#6 Updated by Jurgen Segaert about 1 year ago
I reported this upstream a while ago as https://github.com/iocage/iocage/issues/536
Question/note for Brandon:
For regular jails this can be addressed as part of
iocage update but for basejails (and plugins as a special case of basejails) this would require a different approach, as it nullfs mounts the userland of the "release" upon jail start-up. Not sure what the best way to handle this is; the easiest way seems to execute freebsd-version each time a basejail/plugin is started, and update the release property when it turned out that the "release" was fetched again & patched; Similar to how it sets the "Last started" property each time. Any better ideas? Should the basejail scenario get a different ticket?
#7 Updated by Brandon Schneider about 1 year ago
Jurgen: Basejails actually update the RELEASE they're based on. So I think the best approach is when an update is done for a basejail, nothing changes. But instead when the user tries to get the release, and it is a basejail, we grab the freebsd-version and return that for the latest patch level. Whereas the other jails will have them statically written to the json. But when the user gets this property, we should write it back into the json for future fs reference.
That's the current strategy I'll be employing.
#11 Updated by Brandon Schneider about 1 year ago
Jurgen: As I'm sure you'll see when you look at my commits :D I decided to actually do this during the update method instead. The hope is not to have a tremendous performance cost more than once an update, instead of each time the basejail is interacted with.