Project

General

Profile

Bug #59442

Ensure iocage update correctly updates the release property with the patch level

Added by Sebastien DURIS 11 months ago. Updated 7 months ago.

Status:
Done
Priority:
No priority
Assignee:
Brandon Schneider
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Hi,

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


Related issues

Has duplicate FreeNAS - Bug #62511: iocage does not update version info correctlyClosed
Copied to FreeNAS - Bug #60174: iocage update does not update "release" field in config.json Closed
Copied to FreeNAS - Bug #60183: iocage update does not update "release" field in config.json Closed

History

#1 Updated by Dru Lavigne 11 months ago

  • Assignee changed from Release Council to William Grzybowski

#3 Updated by William Grzybowski 11 months ago

  • Assignee changed from William Grzybowski to Brandon Schneider

#4 Updated by Brandon Schneider 11 months ago

  • Status changed from Unscreened to In Progress

#6 Updated by Jurgen Segaert 11 months 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 11 months 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.

#8 Updated by Bug Clerk 11 months ago

  • Status changed from In Progress to Ready for Testing

#9 Updated by Bug Clerk 11 months ago

  • Target version changed from Backlog to 11.3

#10 Updated by Bug Clerk 11 months ago

  • Copied to Bug #60174: iocage update does not update "release" field in config.json added

#11 Updated by Brandon Schneider 11 months 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.

#12 Updated by Bug Clerk 11 months ago

  • Copied to Bug #60183: iocage update does not update "release" field in config.json added

#13 Updated by Jurgen Segaert 11 months ago

Yep, I know exactly what you mean; That potential for negative performance impact is why I never submitted a PR for this myself but asked the question instead. :-)
Thank you for doing what you do!

#14 Updated by Brandon Schneider 11 months ago

Thanks! I figured as much, appreciate the constant PRs/feedback :)

#15 Updated by Bug Clerk 11 months ago

  • Status changed from Ready for Testing to In Progress

#16 Updated by Bug Clerk 11 months ago

  • Status changed from In Progress to Ready for Testing

#17 Updated by Dru Lavigne 10 months ago

  • Has duplicate Bug #62511: iocage does not update version info correctly added

#18 Updated by Dru Lavigne 9 months ago

  • Target version changed from 11.3 to 11.3-BETA1

#19 Updated by Dru Lavigne 9 months ago

  • Subject changed from iocage update does not update "release" field in config.json to Ensure iocage update correctly updates the release property with the patch level
  • Needs Merging changed from Yes to No

#20 Updated by Dru Lavigne 7 months ago

  • Needs Doc changed from Yes to No

#21 Updated by Brandon Schneider 7 months ago

Not testable via GUI

#22 Updated by Brandon Schneider 7 months ago

  • Status changed from Ready for Testing to Done
  • Needs QA changed from Yes to No

#23 Updated by Dru Lavigne 7 months ago

  • Target version changed from 11.3-BETA1 to 11.3-ALPHA1

Also available in: Atom PDF