-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have upgrade only do /etc merge just before reboot #40
Comments
this is a comment we had in another conversation, I add here to not get it lost: what do you think if we remount /etc as read-only after the upgrade is done? Postponing the merge before the reboot seems a bit risky, as the users won't have the chance to deal with possible errors and do we want to block the reboot in that case? |
Yeah, would likely work...we'd just need to make sure the operating system content was fine with read-only |
This was also hitting the Cockpit tests. |
Any steps in this issue? (I lost some changes because i forget about reboot when doing upgrade =() |
CC #702 |
I think we should fix (most of) this in libostree - main discussion should be in ostreedev/ostree#545 |
Since the whole premise of livefs is that you stay in your deployment just a little longer, it becomes much more likely for people to run into coreos#40 (myself included). Printing such a notice was discussed in the initial livefs design discussions: coreos#639.
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
PR in ostreedev/ostree#1503 |
Closing this one in favor of ostreedev/ostree#545 |
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. Just compile tested, still WIP. For: coreos/rpm-ostree#40
PR: ostreedev/ostree#1503
--
If an admin runs "atomic upgrade", then makes changes to /etc, then reboots, those changes are "lost" (they're still in the old tree).
Fixing this is a bit nontrivial. One simple approach would be to encourage "atomic upgrade -r". Or alternatively, split "atomic prepare-upgrade" -> "atomic apply-upgrade". (The latter gets into making atomic a daemon, so we can use a systemctl isolate target for doing the /etc merging just before reboot)
The text was updated successfully, but these errors were encountered: