-
Notifications
You must be signed in to change notification settings - Fork 290
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 greenboot-like functionality integrated here #2725
Comments
One part of this is probably that OSTree-based distros' default target should probably be systemd's This was also touched upon in the recently held Image-based Linux summit, see: https://github.com/uapi-group/docs/blob/main/minutes/2022-10-05__Image-based-linux-summit.md#prior-art and more generally https://uapi-group.org/ |
This part of the boot specification might be relevant too to avoid creating two different mechanisms: https://github.com/uapi-group/specifications/blob/main/specs/boot_loader_specification.md#boot-counting |
The boot counting mechanism described in the spec and used by sd-boot (i.e. putting the counter in the boot loader entry file) was deemed not implementable with grub, so greenboot implemented its own via a grub snippet and grub env vars. That's what's used by Fedora IoT / RHEL for Edge today. So we already have two different mechanisms unfortunately. |
I am working on the re-write of the greenboot in rust, I am looking for options of how to differentiate a regular reboot vs reboot post upgrade/rollback. @cgwalters as a starter in ostree would like to understand how to
And how different it is from existing greenboot. |
I'd say here we should use the
There's also We could adjust that one to log this as structured data. Now, not every system will have a persistent journal. I could imagine that we record a "last booted" field somewhere in ostree associated with a deployment. That'd be cheaper and more reliable to parse. |
I think this is covered by the initial comment right?
|
Having some discussions on https://pagure.io/fedora-iot/greenboot and I think we should actually fold this functionality into ostree proper. As is the hooks it makes into the "control loop" of OS upgrades are extremely complicated.
In particular I'd like
ostree admin status
to have information about things like boot success etc.I think we can take a new approach here:
ostree-boot-complete.service
to propagate staging failures #2589 ) that marks a successful stateThe text was updated successfully, but these errors were encountered: