Discussion: did anything change in Fedora 43, initramfs issues

Sorry to misuse the issue tracker, but discussions are not enabled for this project. I am not sure, whether it is even a problem with dracut-sshd, but there is certainly something off with the initramfs all of a sudden. I'd like to get some ideas and theories from other users and experts in this area. I've been using dracut-sshd for a while and besides one little issue I had (OpenSSH 9.8 support), which I caught on my test VM, it has been working great all this time. But currently there are a few things that make no sense to me. I run a bare metal server in a DC and I have also access via an iLO. I am using dracut-sshd to unlock my root and data partitions. My test VM I run at home (via Proxmox), which is a logical clone of the server in the DC. Same packages, same kernel, same filesystems, same dracut-sshd (with the only difference in the `motd` file and the IP address). Both use BIOS and not UEFI. I upgraded to Fedora 43 (from 42) without issues on the VM. dracut-sshd still works. Then I upgraded the server (also from 42 to 43). Now the initramfs boot process is stuck (somewhere around the sshd and cryptfs targets), the sshd is not available and it doesn't drop into the emergency shell. So I can't even unlock my hard drives. The problem is, I can't even do so via the iLO (and I don't know why, it is asking me for a password, but then nothing). I was a able to boot with the most recent f42 kernel without issues (entering the password via ssh or iLO). So my server is up and running. (A f43 system now running a f42 kernel.) The problem is, this is a bare metal server, not a VM. The POST takes up to 5 minutes (I have already switched to fast POST in the BIOS), so doing a reset via the iLO for the next debugging session takes 5 minutes. Which is why I have currently taken a break from debugging and just run the f42 kernel. But I will have to figure this out sooner than later. I have a few ideas (e.g. adding different `rd.break=` points to the kernel parameters when grub shows up. changing the `[Match]` section (in the network cfg) from name to mac address (although I can see in the boot process that the interface names have not changed). But I want to get a few more ideas before I announce a maintenance window to debug and hopefully fix this issue. So I am wondering, if someone has experienced a similar behavior before. I am genuinely puzzled over this whole situation. If there were different kernels or packages involved, I would probably think that they are the culprit, but that's not it. They are the same. I'd appreciate any input. Sorry again for the wall of text and misusing the issue tracker.