WIP: takeover installs #78
Draft
+466
−33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Skipping CI for Draft Pull Request. |
cgwalters
force-pushed
the
reexec-switchroot2
branch
2 times, most recently
from
18b683e to
773bdfa
Compare
cgwalters
force-pushed
the
reexec-switchroot2
branch
from
773bdfa to
98fa95e
Compare
cgwalters
force-pushed
the
reexec-switchroot2
branch
from
98fa95e to
5afa24f
Compare
cgwalters
force-pushed
the
reexec-switchroot2
branch
from
5afa24f to
d38a5d5
Compare
cgwalters
added a commit
to cgwalters/bootc
that referenced
this pull request
Sep 22, 2023
I was trying to be really ambitious in containers#78 for the full "takeover" path. This is a *much* *much* simpler variant where we just: - Blow away and reinitialize the `/boot` and `/boot/efi` partitions - Write inside the existing filesystem, leaving the OS running Then when we reboot, we'll just need to clean up the old OS state (or optionally leave it).
cgwalters
added a commit
to cgwalters/bootc
that referenced
this pull request
Sep 23, 2023
I was trying to be really ambitious in containers#78 for the full "takeover" path. This is a *much* *much* simpler variant where we just: - Blow away and reinitialize the `/boot` and `/boot/efi` partitions - Write inside the existing filesystem, leaving the OS running Then when we reboot, we'll just need to clean up the old OS state (or optionally leave it). Signed-off-by: Colin Walters <[email protected]>
This adds `bootc install --takeover` which moves the running container into RAM and invokes `systemctl switch-root` to it, then proceeds with an installation to the previously-used block device. A key use case here is to "takeover" a running cloud instance, e.g. provision the system via cloud-init or so which invokes `podman run --privileged ... bootc install --takeover`. At the current time, this is only scoped to "builtin" installation types. We could support `install-to-filesystem` type flows too by allowing externally-configured block storage setups to be run as part of the current container (or in the fully general case, a distinct container, though that adds a lot of complexity).
cgwalters
force-pushed
the
reexec-switchroot2
branch
from
d38a5d5 to
ab2a45e
Compare
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
lsm: Create tempfile in
/var/tmpThis should more reliably support labeling. Prep for takeover
installs.
Signed-off-by: Colin Walters [email protected]
install: Extract a unified
SourceInfostructThis data keeps track of the container and ostree commit information.
Prep for
install --takeoverwhere we want to serialize this data.Signed-off-by: Colin Walters [email protected]
WIP: takeover installs
This adds
bootc install --takeoverwhich moves the runningcontainer into RAM and invokes
systemctl switch-rootto it, thenproceeds with an installation to the previously-used block device.
A key use case here is to "takeover" a running cloud instance, e.g.
provision the system via cloud-init or so which invokes
podman run --privileged ... bootc install --takeover.At the current time, this is only scoped to "builtin" installation
types. We could support
install-to-filesystemtype flows tooby allowing externally-configured block storage setups to be
run as part of the current container (or in the fully general
case, a distinct container, though that adds a lot of complexity).