greenboot-healthcheck service not active nor preset in RHEL-9.9/RHEL-10.3 aarch64

[mcattamoredhat]

It has been seen that qcow2 test case is failing due to greenboot-healthcheck.service not active in the edge embedded system.
The failure has been detected in RHEL-9.9.0-Nightly compose host os with aarch64 architecture.

TASK [greenboot healthcheck service should be active] **************************************************************************************************************************************************************
fatal: [192.168.100.50]: FAILED! => {"changed": true, "cmd": ["systemctl", "is-active", "greenboot-healthcheck.service"], "delta": "0:00:00.011324", "end": "2026-06-10 15:05:45.059513", "msg": "non-zero return code", "rc": 3, "start": "2026-06-10 15:05:45.048189", "stderr": "", "stderr_lines": [], "stdout": "failed", "stdout_lines": ["failed"]}

Although the advisory list applied to the edge machine seems to include the greenboot-rs services preset, the service is not active, so the greenboot mechanism fails. We cannot restart the service manually (and we shouldn’t).

[core@vm-1 ~]$ !18
rpm -q  --changelog redhat-release 
* Thu May 07 2026 Veronika Doubkova <vdoubkov@redhat.com> - 9.9-0.6
- Update ProductID for 9.9-beta
- Resolves: RHELBLD-18320

* Mon Apr 20 2026 Veronika Doubkova <vdoubkov@redhat.com> - 9.9-0.5
- Remove greenboot-set-success.target
- Resolves: RHELBLD-18188

* Tue Apr 07 2026 Veronika Doubkova <vdoubkov@redhat.com> - 9.9-0.4
- Fix greenboot-rs preset services 
- Resolves: RHELBLD-18188
....

We cannot restart the service manually (and we shouldn’t). So the following failing playbook task failing is an expected failure:

TASK [Attempt manual restart of greenboot-healthcheck service] *****************************************************************************************************************************************************
fatal: [192.168.100.50]: FAILED! => {"changed": true, "cmd": "echo \"exit 1\" > /etc/greenboot/check/required.d/10_failme.sh\nchmod 755 /etc/greenboot/check/required.d/10_failme.sh\nsystemctl restart greenboot-healthcheck\n", "delta": "0:00:00.014575", "end": "2026-06-10 15:16:00.887558", "msg": "non-zero return code", "rc": 4, "start": "2026-06-10 15:16:00.872983", "stderr": "Failed to restart greenboot-healthcheck.service: Operation refused, unit greenboot-healthcheck.service may be requested by dependency only (it is configured to refuse manual start/stop).\nSee system logs and 'systemctl status greenboot-healthcheck.service' for details.", "stderr_lines": ["Failed to restart greenboot-healthcheck.service: Operation refused, unit greenboot-healthcheck.service may be requested by dependency only (it is configured to refuse manual start/stop).", "See system logs and 'systemctl status greenboot-healthcheck.service' for details."], "stdout": "", "stdout_lines": []}
...ignoring

Steps to reproduce

1. Spawn rhel-9.9.0-Nightly aarch64 VM from TF/Beaker
2. Clone greenboot-rs branch (to enable compose testing) ci: allow the installation of greenboot rpm packages from compose #178
3. Deploy edge vm with greenboot-rs embedded as of qcow2 bib generated artifact

cd tests/ && \
sudo \
  DOWNLOAD_NODE="<download-node>" \
  COMPOSE_ID="RHEL-9.9.0-20260525.5" \
  QUAY_USERNAME="<quay-username>" \
  QUAY_PASSWORD="<quay-passwrod>" \
  STAGE_REDHAT_IO_USERNAME="<stage-registry-username>" \
  STAGE_REDHAT_IO_TOKEN="<stage-registry-token>" \
  ./greenboot-bootc-qcow2.sh

4. The greenboot-healthcheck.service should be preset and activated by default for the mechanism to work successfully. But, the service check command returns non-zero code and the playbook task fails.

[mcattamoredhat]

Since service manual restart is not possible, the edge VM has to be undefined to repeat the test, then this is a persistent failure.
We need to investigate and confirm if the service preset applies for all architectures, because this failure is not reproducible in x86_64.

[knecasov]

I confirm that the same problem seems to be present on a VM created using a compose RHEL-10.3-Nightly and an aarch64 architecture.

The reproduction steps differ in:

• the step 1 - Spawn RHEL-10.3-Nightly aarch64 VM using Testing Farm,
• the step 3 - Use COMPOSE_ID=RHEL-10.3-20260522.1 in the command.

Note: The same problem was also observed when running the test script greenboot-bootc-anaconda-iso.sh.