To Reproduce Steps to reproduce the behavior:

1. Complete FFU up to system upgrade [1]
2. Add the LeappInitCommand workaround to system_upgrade.yaml to prevent an issue with EFI as per this article [2]
3. Run the Undercloud system upgrade: openstack undercloud upgrade --yes --system-upgrade /home/stack/templates/system_upgrade.yaml
4. After the command completes without error, reboot the Director node
5. The Director node reboots on RHEL8.4 instead of RHEL9.2. Leapp was not triggered during boot.

Expected behavior

• Leapp gets triggered, and boots to RHEL9.2 after first successful system upgrade / reboot attempt while using 1 unified system_upgrade.yaml file.

Bug impact

• Customer currently needs to workaround other workarounds. They expect that the system_upgrade.yaml file should work with both UC and OC nodes, no matter if they boot legacy/EFI. This delays upgrade for production sites.

Known workaround

• Running the undercloud system upgrade a second time works
• Running the undercloud system upgrade without the LeappInitCommand [2] also seem to work, but then it breaks the OC nodes upgrade. 

Additional context

• The Director is a legacy booting VM
• The Computes are EFI booting baremetal nodes
• Issue with/without the workaround for EFI nodes [2] is tracked here [3] 
• It is suspected that some tripleo-ansible roles running during the RHOSP upgrade steps might be causing this issue

 [1]https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/framework_for_upgrades_16.2_to_17.1/index#upgrading-the-undercloud-operating-system

 [2]https://access.redhat.com/solutions/7096899

[3] https://issues.redhat.com/browse/OSPRH-16320