for simplified greenboot, the greenboot* services are disabled and not started

[yih-redhat]

Issue description:
greenboot service and greenboot-rollback service are disabled and not started

[admin@vm-1 ~]$ systemctl is-enabled greenboot.service greenboot-rollback.service
disabled
disabled

[admin@vm-1 ~]$ journalctl --list-boots
IDX BOOT ID FIRST ENTRY LAST ENTRY
0 1fd7bf376e634d0298540a6715cfa976 Wed 2023-07-19 04:58:22 EDT Wed 2023-07-19 07:15:38 EDT

[admin@vm-1 ~]$ journalctl -b -0 -u greenboot.service
– No entries –

[LorbusChris]

What OS is this? What version of greenboot are you running?

Please format code and logs by adding 3 backticks before and after:

like this

[LorbusChris]

For services to be auto-enabled, they have to have a preset config. For Fedora IoT, that's here: https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/80-iot.preset

[yih-redhat]

It's for simplified greenboot, from @say-paul : the service will be enabled from osbuild-composer/presets which is not done yet, so it has to be manually enabled.
This issue is to track this task.

[nullr0ute]

Where possible we should keep the service names the same so things like this don't need to change else it will likely cause issues with upgrade paths.

[say-paul]

makes sense,
we can keep the greenboot-healthcheck.service(instead of greenboot.service) which does the healthcheck.
but for redboot-auto-rollback.service which handles rollback we need to rename it to greenboot-rollback.service since we are not using redboot. target anymore.

[nullr0ute]

but for redboot-auto-rollback.service which handles rollback we need to rename it to greenboot-rollback.service since we are not using redboot. target anymore.

Can we deal with upgrade paths there with dependencies/wants etc?

[say-paul]

I guess that needs to be implemented. thanks for pointing that out.

[say-paul]

I have modified greenboot to greenboot-healthcheck , and tested with image based update rpm-ostree upgrade it worked correctly, old services got removed but I thinks its due ostree.
I think there will be still concerns for traditional install process, I need to retest that ,we can tackle this issue as a separate PR , instead of pushing in already a very big #100