Skip to content
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

Add a hidden bootc install wipe-ostree #776

Closed
omertuc opened this issue Sep 4, 2024 · 8 comments
Closed

Add a hidden bootc install wipe-ostree #776

omertuc opened this issue Sep 4, 2024 · 8 comments

Comments

@omertuc
Copy link
Contributor

omertuc commented Sep 4, 2024

Right now the integration tests have some hacky code to clear out ostree stateroots (reset_root), it would be better if they could rely on a bootc command to take care of that for them instead

Originally posted by @cgwalters in #622 (comment)

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

To that end @cgwalters suggested we use Storage::write_deployments with an empty slice, but unfortunately getting a Storage instance to operate on through get_storage requires us to run inside a bootc-booted system, which is unsupported for running integration tests, so we need to manually implement the ostree directory deletion similarly to how the tests do it today or find a way around that

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

Even while avoiding the get_storage lock and instead running:

let sysroot = ostree::Sysroot::new_default();
sysroot.set_mount_namespace_in_use();
sysroot.load(gio::Cancellable::NONE)?;
sysroot
    .write_deployments(&[], gio::Cancellable::NONE)
    .context("removing deployments")?;

The /ostree/deploy/foo directory seems to stay intact

@cgwalters
Copy link
Collaborator

Yeah, removing a deployment doesn't remove a stateroot today. But it should take care of the /ostree/deploy/$stateroot/<deploy> directories with their immutable bits etc.

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

Yeah, removing a deployment doesn't remove a stateroot today. But it should take care of the /ostree/deploy/$stateroot/<deploy> directories with their immutable bits etc.

Ah of course, that makes sense. In that case, it seems to have done the job correctly. I'll try to plug it in the tests cleanup function in place of all the chattr stuff and see if it passes

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

Nah actually it didn't seem to work:

omer@localhost-live:~/bootc$ sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers --pid=host --security-opt label=disable -v /ostree:/ostree localhost/bootc bootc state wipe-ostree
omer@localhost-live:~/bootc$ sudo rm -rf /ostree/deploy/default/
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/bin': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/home': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/lib': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/lib64': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/media': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/mnt': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/ostree': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/root': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/sbin': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/srv': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/boot': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/dev': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/opt': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/proc': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/run': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/sys': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/sysroot': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/tmp': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/usr': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/var': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/.ostree.cfs': Operation not permitted
rm: cannot remove '/ostree/deploy/default/deploy/a0003fa2e1d3d750a4d8ffc1f45c6eb5903049ebc533024255a4a1549d273d1f.0/etc': Operation not permitted

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

Or maybe it's just due to insufficient mounts, if I do this instead:

omer@localhost-live:~/bootc$ sudo cp $(sudo podman mount $(sudo podman create localhost/bootc))/usr/bin/bootc binary
omer@localhost-live:~/bootc$ sudo ./binary state wipe-ostree
omer@localhost-live:~/bootc$ sudo rm -rf /ostree/deploy/default/

it works

Maybe the lack of /boot directory is making ostree write_deployments into a no-op, checking

@cgwalters
Copy link
Collaborator

Maybe the lack of /boot directory is making ostree write_deployments into a no-op, checking

Yeah it's that

@omertuc
Copy link
Contributor Author

omertuc commented Sep 5, 2024

Maybe the lack of /boot directory is making ostree write_deployments into a no-op, checking

Yeah it's that

Yep confirmed

omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.
omertuc added a commit to omertuc/bootc that referenced this issue Sep 5, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.

Signed-off-by: Omer Tuchfeld <[email protected]>
omertuc added a commit to omertuc/bootc that referenced this issue Sep 6, 2024
Solves containers#776

Right now the integration tests have some hacky code to clear out
`ostree` stateroots  (see `reset_root` function), it would be better if
they could rely on a bootc command to take care of that for them instead

This commit adds a new `state wipe-ostree` subcommand to the CLI that
removes all `ostree` deployments from the system using native ostree
bindings. This makes it easier to later rm -rf the stateroots and have a
clean slate for the next test.

Signed-off-by: Omer Tuchfeld <[email protected]>
@omertuc omertuc closed this as completed Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants