|
| 1 | +# Factory reset with `bootc install reset` |
| 2 | + |
| 3 | +This is an experimental feature; use `--experimental` flag to acknowledge. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +The `bootc install reset` command allows you to perform a non-destructive factory reset of an existing bootc system. This creates a fresh installation state in a new stateroot while preserving the existing system's files on disk. After rebooting into the new deployment, you can still access the old system's data by examining files in `/sysroot/ostree/deploy/<old-stateroot>/`. |
| 8 | + |
| 9 | +## How it works |
| 10 | + |
| 11 | +When you run `bootc install reset`: |
| 12 | + |
| 13 | +1. A new stateroot is created with an automatically generated name (format: `state-<year>-<serial>`, e.g., `s2025-0`) |
| 14 | +2. A fresh deployment is created in the new stateroot using the currently booted image (or optionally a different image via `--target-imgref`) |
| 15 | +3. Kernel arguments related to root filesystem configuration are automatically inherited from the current deployment |
| 16 | +4. The `/boot` fstab entry is preserved from the current system if it exists |
| 17 | +5. The new deployment becomes the default boot target |
| 18 | + |
| 19 | +After rebooting, you'll be running in a completely fresh system state: |
| 20 | +- `/etc` contains only the configuration from the container image |
| 21 | +- `/var` is empty (no user data or state from the previous system) |
| 22 | +- The old stateroot's files remain on disk at `/sysroot/ostree/deploy/<old-stateroot>/` and can be accessed for data recovery or inspection |
| 23 | + |
| 24 | +## Usage |
| 25 | + |
| 26 | +Basic usage (reset to the same image currently running): |
| 27 | + |
| 28 | +```bash |
| 29 | +bootc install reset --experimental |
| 30 | +``` |
| 31 | + |
| 32 | +Reset and switch to a different image: |
| 33 | + |
| 34 | +```bash |
| 35 | +bootc install reset --experimental --target-imgref quay.io/example/myimage:latest |
| 36 | +``` |
| 37 | + |
| 38 | +Reset with custom stateroot name: |
| 39 | + |
| 40 | +```bash |
| 41 | +bootc install reset --experimental --stateroot production-2025 |
| 42 | +``` |
| 43 | + |
| 44 | +Reset and immediately reboot: |
| 45 | + |
| 46 | +```bash |
| 47 | +bootc install reset --experimental --apply |
| 48 | +``` |
| 49 | + |
| 50 | +Add custom kernel arguments: |
| 51 | + |
| 52 | +```bash |
| 53 | +bootc install reset --experimental --karg=console=ttyS0,115200n8 |
| 54 | +``` |
| 55 | + |
| 56 | +Skip inheriting root filesystem kernel arguments: |
| 57 | + |
| 58 | +```bash |
| 59 | +bootc install reset --experimental --no-root-kargs |
| 60 | +``` |
| 61 | + |
| 62 | +## Kernel arguments |
| 63 | + |
| 64 | +By default, `bootc install reset` automatically inherits kernel arguments from the currently booted deployment that are related to root filesystem configuration. This includes: |
| 65 | + |
| 66 | +- `root=` - Root device specification |
| 67 | +- `rootflags=` - Root filesystem mount options |
| 68 | +- `rd.*` arguments - Initramfs arguments (e.g., for LVM, LUKS, network root) |
| 69 | +- Kernel arguments defined in `/usr/lib/bootc/kargs.d/` and `/etc/bootc/kargs.d/` |
| 70 | + |
| 71 | +You can: |
| 72 | +- Add additional kernel arguments with `--karg` (can be specified multiple times) |
| 73 | +- Skip automatic root filesystem argument inheritance with `--no-root-kargs` |
| 74 | + |
| 75 | +## Use cases |
| 76 | + |
| 77 | +- **Development/testing**: Quickly return to a clean state while preserving the ability to boot back to your development environment |
| 78 | +- **Troubleshooting**: Reset to a known-good state without losing access to the problematic deployment for debugging |
| 79 | +- **System refresh**: Start fresh after accumulating configuration changes, while keeping the old state accessible |
| 80 | +- **Image testing**: Test a new image version in a separate stateroot before committing to it |
| 81 | + |
| 82 | +## Cleaning up the old stateroot |
| 83 | + |
| 84 | +After performing a factory reset and rebooting into the new stateroot, the old stateroot remains on disk at `/sysroot/ostree/deploy/<old-stateroot>/`. This allows you to access files from the previous system if needed. |
| 85 | + |
| 86 | +Once you no longer need the old stateroot, you can remove it to free up disk space: |
| 87 | + |
| 88 | +1. First, remove any remaining deployments from the old stateroot: |
| 89 | + |
| 90 | +```bash |
| 91 | +# List all deployments to find the old stateroot's deployment index |
| 92 | +ostree admin status |
| 93 | + |
| 94 | +# Remove the old deployment(s) by index |
| 95 | +# The index is shown in the output (e.g., "1" for the second deployment) |
| 96 | +ostree admin undeploy <index> |
| 97 | +``` |
| 98 | + |
| 99 | +2. After all deployments from the old stateroot are removed, you can delete the stateroot directory: |
| 100 | + |
| 101 | +```bash |
| 102 | +# Replace "default" with your old stateroot name if different |
| 103 | +mount -o remount,rw /sysroot |
| 104 | +rm -rf /sysroot/ostree/deploy/default |
| 105 | +``` |
| 106 | + |
| 107 | +**Note:** You cannot remove the stateroot directory while deployments still exist in it. OSTree protects deployment directories with filesystem-level mechanisms, so you must undeploy them first using `ostree admin undeploy`. |
| 108 | + |
| 109 | +## Limitations |
| 110 | + |
| 111 | +- This command requires `--experimental` flag as the feature is still under development |
| 112 | +- Only works on systems already running bootc (not for initial installations) |
| 113 | +- The old stateroot is not automatically removed and will consume disk space until manually deleted (see "Cleaning up the old stateroot" section above) |
| 114 | + |
| 115 | +## See also |
| 116 | + |
| 117 | +- `bootc switch` - Switch to a different container image |
| 118 | +- `bootc status` - View current deployment status |
0 commit comments