@okay_awright: thanks!

There are reports of Dracut 0.53 possibly breaking the initramfs in bugzilla:

• https://bugzilla.redhat.com/show_bug.cgi?id=1945596 Can't boot with initramfs generated by dracut-0.53
• https://bugzilla.redhat.com/show_bug.cgi?id=1945426 hang on boot with the update containing kernel 5.11.11
• https://bugzilla.redhat.com/show_bug.cgi?id=1945950 dracut-053 renders system unbootable

@antiv, @kalvinist, @okay_awright What does the following commands output?

lsinitrd /boot/initramfs-5.11.10-300.*.img |egrep '^(Image|Version|Arguments)'
lsinitrd /boot/initramfs-5.11.11-300.*.img |egrep '^(Image|Version|Arguments)'

I'm not sure if it's related but I briefly ran into an issues with "zram: Cannot change disksize for initialized device" or rngd being stuck at some point on a Raspberry Pi 4, which was bootstrapped via UEFI/iPXE with the PXE kernel and initrd, installed in text mode with btrfs ("use entire disk") and upgraded with dnf update -y. The zram issue caused a bunch of services to fail during startup and prevented me from logging in on the console.

Unfortunately I'm not sure what caused either of these issues this since I did a whole bunch of Fedora Server installs in a short run, most of which failed for various reasons (mostly PEKBAC):

• UEFI/iPXE booted a 5.11.10 kernel with inst.repo set to a local mirror which likely lagged behind 1-2 days with respect to packages
• UEFI/iPXE booted a 5.11.11 kernel with inst.repo set to the same, local mirror
• ran dnf update -y after the install
• dabbled with an option to disable "Limit RAM to 3GB" in UEFI for Raspberry Pi 4 (its enabled by default in EDK2 UEFI)
• booted the system via u-boot and GRUB2 without knowing exactly which of my three disks (all attached to the same Raspberry Pi, each having a throwaway install of F34) it booted from

Anyways, in the end I succeeded with an install which was UEFI/iPXE booted with the PXE vmlinuz (5.11.11) and initrd.img from https://dl.fedoraproject.org/pub/fedora/linux/development/34/Server/aarch64/ (with inst.repo set to the same mirror).

I've run dnf update -y and dracut --regenerate-all --force (dracut 053) with no issues on a Raspberry Pi 4. Currently I'm running dracut 053-1.fc34, kernel 5.11.11-300.fc34 and systemd 248-1.fc34.

FWIW: F34 Beta shipped with Dracut 0.51 (see https://github.com/dracutdevs/dracut/releases) and a 5.11.10 kernel. The initrd.img built by this version of Dracut lacked most MDIO drivers, needed by Raspberry Pi among others, due to a driver location change in kernel 5.10. As noted in https://bugzilla.redhat.com/show_bug.cgi?id=1943983, this was fixed in https://github.com/dracutdevs/dracut/commit/3c8ca29 (shipped in Dracut 0.52 and 0.53). Dracut 0.53 went stable in F34 about a day ago.

Initial testing on a Raspberry Pi 4 with dracut, dracut network and rescue initrds suggests this works as intended.