On Fri, Jul 25, 2025 at 08:01:14AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jul 24, 2025 at 11:08:07PM +0100, Aoife Moloney via devel-announce wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/Greenboot_RS_Change_Proposal > > > == Summary == > > A rewrite of Greenboot written in Rust will be released, designed for > > use with bootc and rpm-ostree based systems. This Greenboot release > > will have the same functionality as the original Bash release, which > > was only intended for rpm-ostree based systems. > > > Greenboot consists of two packages: `greenboot` and > > `greenboot-default-health-checks`. The former, `greenboot` comprises > > all the core functionalities of Greenboot. This includes checking > > provided scripts and binaries, rebooting when required scripts or > > binaries fail, and rolling back to a previous deployment if the > > problem remains unsolved. The second package, > > `greenboot-default-health-checks`, contains a series of optional > > health checks curated and provided by the Greenboot maintainers. > > > > A Greenboot execution begins on boot with > > `greenboot-healthcheck.service`, which runs before systemd's > > `boot-complete.target`. It launches `/usr/libexec/greenboot/greenboot > > check`, which runs the `required.d` and `wanted.d` scripts. > > There is a significant overlap between the systemd framework for this, > i.e. boot-complete.target, and the greenboot framework. Greenboot > *partially* ties into the systemd framework, at least by ordering > before boot-complete.target, but it also partially sidesteps it, by > managing the reboot itself. Since you're investing new work into > this, would it be possible to remove this duplication? It'd definitely > be beneficial for users to have a _single_ documented framework for > this, with a uniform interface on all systems. Also, obviously with > less duplicated work, we can have one system that works better. Bump. -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
