The posttrans script does:

```
if grep -q "configfile" ${EFI_HOME}/grub.cfg; then
    exit 0 # already unified, nothing to do
fi

[...]

cp -a ${EFI_HOME}/grub.cfg ${EFI_HOME}/grub.cfg.rpmsave
cp -a ${EFI_HOME}/grub.cfg ${GRUB_HOME}/
mv ${EFI_HOME}/grub.cfg.stb ${EFI_HOME}/grub.cfg
```

That means that if the EFI grub.cfg does NOT contain "configfile", it copies it to /boot/grub2/grub.cfg under the assumption that it is a full-blown GRUB config (if there is none at all, it generates one correctly).

The EFI stub grub.cfg generated by Kiwi uses "source" instead of "configfile". That means it is not recognized, so posttrans clobbers the real grub.cfg with it on the next upgrade. This leads to an infinite loop on boot, as the main /boot/grub2/grub.cfg is now a stub script that sources itself.

The script should either NOT clobber the main /boot/grub/grub.cfg at all ever, or it should unconditionally regenerate it with grub2-mkconfig (as already happens indirectly when there is no EFI config at all). Blindly copying over /boot/efi/EFI/fedora/grub.cfg to /boot/grub/grub.cfg is a recipe for disaster.

Right now, every Fedora Asahi users who upgrades their system is at risk of this failure mode and an unbootable system (depending on other conditions, which could cause grub.cfg to be regenerated and fixed). Marking urgent as we're getting more and more users making their systems unbootable with a simple upgrade as a result of this bug.

Reproducible: Sometimes

Steps to Reproduce:
1. Install Fedora Asahi prior to a GRUB upgrade
2. Upgrade
3. Be unlucky that nothing else regenerated grub.cfg to fix the mess as part of the upgrade.
Actual Results:  
System hangs on boot. Recovery is a major pain in the ass, involving typing a pile of u-boot/grub commands to avoid hitting the infinite loop and getting a kernel to load.

Expected Results:  
System continues to boot.