The issue is due to RHEL-95391.
Usually customers having systems with disks configured in software raid have a resume=UUID=xxx statement on the kernel command line.
But it seems not always to be the case, a customer also got systems with resume=/dev/md/swap statement instead. This actually happened for half of a customer's systems (2 out of 4) and the statement got written at installation time by Anaconda itself.

Due to RHEL-95391, when having such statement, leapp reboot phase hangs forever waiting for the device forever.
The reason is leapp is rebooting with a host-only initramfs but having the /etc/mdadm.conf explicitly remove (through using --nomdadmconf dracut option).

I think we need an inhibitor for this: if some MD device is specified as /dev/md/xxx, whenever on the kernel command line or in /etc/fstab, the upgrade command should fail.
Alternatively the mdadm configuration should be embedded in the initramfs (I don't know why it's not the case btw).