Skip to content

lib: add support for soft-reboots #1392

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jmarrero
Copy link
Contributor

@jmarrero jmarrero commented Jun 30, 2025

Closes: #1350

depends on

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds support for soft-reboots. The implementation has code duplication in lib/src/cli.rs and lib/src/status.rs. An unnecessary backup file (lib/src/status.rs.orig) has been included and must be removed.

@jmarrero jmarrero force-pushed the soft-reboots branch 4 times, most recently from f063416 to 825778d Compare July 8, 2025 13:51
@jmarrero jmarrero marked this pull request as ready for review July 8, 2025 13:51
@jmarrero jmarrero changed the title wip: add support for soft-reboots lib: add support for soft-reboots Jul 8, 2025
Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good in general!

lib/src/cli.rs Outdated
let deployments_list = sysroot.deployments();
let staged_deployment = deployments_list
.iter()
.find(|d| d.is_staged())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is what we need to do at the moment, the code is fine.

However just looking at things overall, we should probably try to refactor in the future so that we have a clear staged state that has both the status object and the deployment and we shouldn't then need the unwrap_or and error checking here.

@jmarrero jmarrero force-pushed the soft-reboots branch 3 times, most recently from 408dbd9 to b5ec31d Compare July 9, 2025 17:17
@cgwalters cgwalters marked this pull request as draft July 16, 2025 18:00
@cgwalters
Copy link
Collaborator

Moving to draft since this is blocked until we either:

  • ship an updated ostree
  • switch to build/runtime conditionals

@cgwalters
Copy link
Collaborator

That said one thing that would be cool would be us keeping cached container images for PRs on ghcr.io/bootc-dev/bootc-pr-<PRNUMBER> or so.

In this PR (actually the dependency one) we could explicitly bump the ostree version even before it's shipped $everywhere.

@cgwalters
Copy link
Collaborator

This will require ostreedev/ostree#3487

@jmarrero
Copy link
Contributor Author

On..
[ ] debug why centos stream 9 still has old ostree

it's https://gitlab.com/redhat/centos-stream/containers/bootc/-/merge_requests/641#b1795a50b9b140a9b6dcd2d5c10d39bc56d39805 that has not merged because ppc build does not pass with:
https://konflux-ui.apps.stone-prd-rh01.pg1f.p1.openshiftapps.com/ns/centos-bootc-tenant/applications/centos-bootc-c9s/pipelineruns/centos-bootc-c9s-on-pull-request-m26gv/logs?task=build-container-ppc64le

>>>> Executing `postprocess` inline script '9' <<<<

+ mkdir -p /usr/lib/ostree
+ cat

>>>> Executing `postprocess` inline script '10' <<<<

+ /usr/bin/bootupctl backend generate-update-metadata

>>>> Executing `postprocess` inline script '11' <<<<

+ rm -vrf /usr/lib/ostree-boot/loader
rm: write error: Bad file descriptor
error: Executing compose install: Subprocess failed: ExitStatus(unix_wait_status(256))
rpm-ostree version: 2025.9
warning: Signature not supported. Hash algorithm SHA1 not available.

(/proc/self/exe compose install:733): libdnf-WARNING **: 05:30:13.060: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras
error: Installing packages: Executing inline postprocessing script: bwrap(/usr/bin/rpmostree-postprocess-inline-11): Child process exited with code 1

Error executing command: Command '['rpm-ostree', 'compose', 'rootfs', '--source-root=/', '/usr/share/doc/bootc-base-imagectl/manifests/standard.yaml', '/target-rootfs']' returned non-zero exit status 1.
subprocess exited with status 1
subprocess exited with status 1
Error: building at STEP "RUN --mount=type=cache,target=/workdir . /cachi2/cachi2.env &&     /src/build.sh": exit status 1
step-prepare-sboms :-

which I think is the issue coreos/rpm-ostree#5436 @cgwalters was debugging this week right? Should I just force merge that MR since the new rpm-ostree is on the way?

@cgwalters
Copy link
Collaborator

Sorry yes I edited that TODO item to link to the issue.

Should I just force merge that MR since the new rpm-ostree is on the way?

Which MR?

@jmarrero
Copy link
Contributor Author

Sorry yes I edited that TODO item to link to the issue.

Should I just force merge that MR since the new rpm-ostree is on the way?

Which MR?

I was talking about https://gitlab.com/redhat/centos-stream/containers/bootc/-/merge_requests/641which is a bad idea either way since it will break ppc until we get rpm-ostree.

@jmarrero jmarrero force-pushed the soft-reboots branch 2 times, most recently from 0019619 to fa6bde3 Compare August 1, 2025 18:46
@jmarrero jmarrero force-pushed the soft-reboots branch 6 times, most recently from 885e55e to 7814631 Compare August 8, 2025 16:52
@jmarrero jmarrero force-pushed the soft-reboots branch 4 times, most recently from 4d22a43 to d82acda Compare August 12, 2025 13:17
@jmarrero
Copy link
Contributor Author

man... this is so sad:

 Problem: cannot install both ostree-libs-2025.4-1.el9.x86_64 from appstream and ostree-libs-2025.4-2.el9.x86_64 from @System
  - package ostree-devel-2025.4-1.el9.x86_64 from crb requires ostree-libs(x86-64) = 2025.4-1.el9, but none of the providers can be installed
  - package ostree-2025.4-2.el9.x86_64 from @System requires ostree-libs(x86-64) = 2025.4-2.el9, but none of the providers can be installed
  - cannot install the best candidate for the job

But at least https://gitlab.com/redhat/centos-stream/containers/bootc/-/merge_requests/685/diffs is merged and should resolve this hopefully today.

@jmarrero jmarrero requested a review from cgwalters August 12, 2025 13:25
@bshephar bshephar mentioned this pull request Aug 13, 2025
@jmarrero jmarrero marked this pull request as ready for review August 13, 2025 14:32
@jmarrero
Copy link
Contributor Author

@jmarrero
Copy link
Contributor Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for soft reboots in bootc for upgrade, switch, and rollback commands. The changes include adding a --soft-reboot CLI option, implementing the logic to check for soft reboot capability, and preparing the system for a soft reboot when applicable. The implementation correctly handles different modes (required and auto) and integrates with the existing ostree deployment mechanisms. My review focuses on improving code maintainability by reducing duplication and refactoring complex closures. Overall, the changes are well-implemented and include corresponding tests.

This will enable soft reboots.

Signed-off-by: Colin Walters <[email protected]>
This commit adds --soft-reboot=required|auto to the
cli which uses the ostree api's to setup soft-reboots
during switch, update and rollback operations.

Co-authored-by: Colin Walters <[email protected]>

Signed-off-by: Joseph Marrero Corchado <[email protected]>
Signed-off-by: Colin Walters <[email protected]>
@jmarrero
Copy link
Contributor Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds support for soft reboots, a feature that allows for faster, userspace-only restarts when possible. The changes include new command-line options, logic to detect soft-reboot capability, and integration into the upgrade, switch, and rollback flows. My review focuses on improving code structure for better maintainability by reducing duplication and simplifying control flow.

Comment on lines +808 to +825
let can_soft_reboot = has_soft_reboot_capability(entry);
match mode {
SoftRebootMode::Required => {
if can_soft_reboot {
execute_soft_reboot()?;
} else {
anyhow::bail!(
"Soft reboot was required but {} deployment is not soft-reboot capable",
deployment_type
);
}
}
SoftRebootMode::Auto => {
if can_soft_reboot {
execute_soft_reboot()?;
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The logic in this match statement can be simplified to be more concise and arguably easier to read by handling the can_soft_reboot check first.

    let can_soft_reboot = has_soft_reboot_capability(entry);

    if can_soft_reboot {
        execute_soft_reboot()?;
    } else if matches!(mode, SoftRebootMode::Required) {
        anyhow::bail!(
            "Soft reboot was required but {} deployment is not soft-reboot capable",
            deployment_type
        );
    }

Comment on lines +83 to +88
/// Configure soft reboot behavior.
///
/// 'required' will fail if soft reboot is not available.
/// 'auto' will use soft reboot if available, otherwise fall back to regular reboot.
#[clap(long = "soft-reboot", conflicts_with = "check")]
pub(crate) soft_reboot: Option<SoftRebootMode>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The soft_reboot option, including its documentation, is duplicated across UpgradeOpts, SwitchOpts, and RollbackOpts. This could become a maintainability issue.

Consider factoring out this common option to avoid repetition. A #[clap(flatten)] struct could be an option if the conflicts_with attribute can be handled. Another approach could be a macro to generate the field.

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

Successfully merging this pull request may close these issues.

Support for soft reboots
4 participants