From what I can tell, FOG is handling the UUID’s correctly…
Would say so too from what we discovered so far. It’s interesting you can capture/deploy from/to VM<->VM and machine<->machine but not “across”.
For further debugging I suggest to dig into the dracut emergency shell/mode more. First run ls -al /dev/disk/by-uuid/ on the dracut command prompt and post a picture of that here. As well you might also follow the instrcutions printed, run journalctl and look through the log for hints on why it fails booting. Also take a look at the file /run/initramfs/rdsosreport.txt mentioned. Feel free to share the file here and I’ll take a look as well.
Searching the web I found this: https://unix.stackexchange.com/questions/183859/initramfs-uuid-problems-after-cloning
Sounds like the initramfs might be generated differently on your VM and bare metal install. Both are missing a driver for the other one. If that turns out to be true you need to find out which one is missing and manually regenerate initramfs with dracut e.g. on your VM before capturing the image to be deployed to hardware.