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.

Sign up for GitHub

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

Jump to bottom

install: Support reinstallation (factory reset) #404

Open
cgwalters opened this issue Mar 19, 2024 · 6 comments
Open

install: Support reinstallation (factory reset) #404

cgwalters opened this issue Mar 19, 2024 · 6 comments
Labels
area/install Issues related to `bootc install` enhancement New feature or request

Comments

@cgwalters
Copy link
Collaborator

cgwalters commented Mar 19, 2024 •
edited
Loading

#137 is tracking part of this, a lot of related discussion in coreos/fedora-coreos-tracker#399

Basically we should support something like bootc install factory-reset that would configurably wipe local system state.

On the implementation side...I think the best way to do this would be something like:

  • Create new deployment with fresh etc targeting a new stateroot
  • Boot into it
  • optional: clean up old deployment + stateroot

The beauty of this approach is that the "factory reset" would actually also be fully transactional, i.e. you could roll back into the previous state. It'd be easy to copy over any desired state (SSH host keys, cached container images e.g.) from the previous boot before deleting it.
@cgwalters cgwalters added area/install Issues related to `bootc install` enhancement New feature or request labels Mar 19, 2024
@cgwalters cgwalters changed the title install: Support reinstallation install: Support reinstallation (factory reset) Mar 20, 2024
@cgwalters
Copy link
Collaborator Author

BTW one tricky thing in this is kernel arguments...cc #401

And also related to this, we should probably go to some effort to preserve the original kargs.

An entirely different way to implement this would be to retain a pinned version of the original installed deployment. Some people will want to do that, and we already effectively support it with ostree admin pin. However...rolling back to that in the general case will imply rolling back to something pretty outdated, which we don't want to encourage. So I think we should focus more on better capturing and maintaining the bits of state that we want from that which mostly I think boils down to kargs.

@cgwalters
Copy link
Collaborator Author

One question came up tangentially related to this too - why does the current install integration test suite not work on an ostree based system?

First there's two things; the to-disk code; that works everywhere, it's easy we just use loopback.

For the alongside install tests, it's basically because of this. We'd need to be sure to use an alternative stateroot vs the booted one, etc.

@omertuc omertuc mentioned this issue Sep 5, 2024
Closed
@cgwalters cgwalters mentioned this issue Sep 11, 2024
Open
@vrothberg
Copy link
Member

I'd love to have such a reset functionality for bootc-{switch,update} as well.

@cgwalters cgwalters mentioned this issue Oct 16, 2024
Closed
@kfox1111
Copy link

Maybe an option to reset state on just a single file in etc or a path under etc too, rather then a complete reset.

@cgwalters cgwalters mentioned this issue Oct 22, 2024
Merged
This was referenced Nov 5, 2024
Open
Open
@castrojo castrojo mentioned this issue Nov 7, 2024
Closed
cgwalters added a commit to cgwalters/bootc that referenced this issue Dec 19, 2024
@cgwalters
install feature is always on, add install-to-disk
614b14f 
I consider `bootc install to-filesystem` support a key feature of bootc.
In theory today one can still set up a system directly with `ostree`
and we will continue to support that.

But things like logically bound images we do want to be initialized
from the start and that's with `bootc install to-filesystem`.

Maintaining the feature just has a logistical annoyance any
time one touches the install code as we often end up needing
to carefully `#[cfg(feature = "install")]` in many places
in an infectious way.

Also as we head towards enabling factory reset
containers#404
we really do want some of the install code enabled there.

However, `to-disk` is much more of a "demo". I don't want
bootc to grow too much knowledge around block devices. Complex
setups (LVM, LUKS) etc. are the domain of external installers
and provisioning tools.

So the feature gate is now on that (which is still on by default).

We ended up with more `#[cfg(feature = "install-to-disk")]` than
I'd have liked, but some of that can be fixed subsequently.

Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters cgwalters mentioned this issue Dec 19, 2024
Merged
cgwalters added a commit to cgwalters/bootc that referenced this issue Dec 20, 2024
@cgwalters
install feature is always on, add install-to-disk
43fcd89 
I consider `bootc install to-filesystem` support a key feature of bootc.
In theory today one can still set up a system directly with `ostree`
and we will continue to support that.

But things like logically bound images we do want to be initialized
from the start and that's with `bootc install to-filesystem`.

Maintaining the feature just has a logistical annoyance any
time one touches the install code as we often end up needing
to carefully `#[cfg(feature = "install")]` in many places
in an infectious way.

Also as we head towards enabling factory reset
containers#404
we really do want some of the install code enabled there.

However, `to-disk` is much more of a "demo". I don't want
bootc to grow too much knowledge around block devices. Complex
setups (LVM, LUKS) etc. are the domain of external installers
and provisioning tools.

So the feature gate is now on that (which is still on by default).

We ended up with more `#[cfg(feature = "install-to-disk")]` than
I'd have liked, but some of that can be fixed subsequently.

Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters added a commit to cgwalters/bootc that referenced this issue Dec 20, 2024
@cgwalters
install feature is always on, add install-to-disk
3e6ea48 
I consider `bootc install to-filesystem` support a key feature of bootc.
In theory today one can still set up a system directly with `ostree`
and we will continue to support that.

But things like logically bound images we do want to be initialized
from the start and that's with `bootc install to-filesystem`.

Maintaining the feature just has a logistical annoyance any
time one touches the install code as we often end up needing
to carefully `#[cfg(feature = "install")]` in many places
in an infectious way.

Also as we head towards enabling factory reset
containers#404
we really do want some of the install code enabled there.

However, `to-disk` is much more of a "demo". I don't want
bootc to grow too much knowledge around block devices. Complex
setups (LVM, LUKS) etc. are the domain of external installers
and provisioning tools.

So the feature gate is now on that (which is still on by default).

We ended up with more `#[cfg(feature = "install-to-disk")]` than
I'd have liked, but some of that can be fixed subsequently.

Signed-off-by: Colin Walters <walters@verbum.org>
@Malix-Labs
Copy link

Hello folks, is there a clear path of what to do next to make this happen?

@cgwalters
Copy link
Collaborator Author

So #137 landed some important preparatory code here. However...that's covering the "reinitialize system from a different bootc container image". What we obviously could streamline is the flow of "reinitialize system from the booted image".

Probably something like bootc install to-existing-root --from-booted? And we need to bikeshed what state preservation options we support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/install Issues related to `bootc install` enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cgwalters @kfox1111 @vrothberg @Malix-Labs