Hello,
On Fedora 43 after updating the system I cannot boot anymore.
Journalctl shows:
mount: /boot/efi: unknown filesystem type ‘vfat’.
I have tried to regenerate the initramfs images with dracut command but it is still KO.
Would you please have any ideas?
Can you boot into an older kernel?
There are some good possible solutions at Reddit - The heart of the internet
The same problem happens to all the kernels and fedora versions on my GRUB, except for the rescue mode. I already looked on Reddit but most of the results are for Arch and I’m not sure about what’s causing the problem, I’m not very familiar with partitions. I flashed Fedora Workstation on a drive that was lying around, it boots without issues and it allows me to access to my /home directory but I don’t know if that can help.
The concepts in Arch are the same as Fedora, but the commands are sometimes different.
Essentially from what I can see, the vfat kernel module is not loading for some reason.
Forcing it to load, or putting in a working kernel that is properly matched should get you up and running.
If you boot into your live USB and chroot to the old system, you can get it working from there.
Sorry for the partial answer…
Oh, yeah, I already tried to do that using systemd-nspawn to regenerate the initramfs, but it made the whole thing worse because I think it depended on the mount point I had set up in the live ISO (on /mnt).
I’d be happy if you could provide a detailed answer, but it’s not very urgent.
You could try editing /etc/fstab to comment out the mount for now.
To my knowledge, you shouldn’t actually need to have /boot/efi mounted for anything except reinstalling GRUB.
this looks like a mismatch in kernel versions, kernel can’t load the kernel modules installed on disk. The rescue kernel has most important kernels modules available in the initramfs file.
do you see any output for this command ?
rpm -V $( rpm -qa kernel\* )
post output of
grep boot /etc/fstab
lsblk -f /dev/<the device with the efi partition> # e.g. lsblk -f /dev/nvme0n1
ls -l /boot/
ls -l /lib/modules/
du -sh /lib/modules/
sudo grubby --info=ALL
The first command does not return anything.
Here are the results of the others:
Also, commenting out /boot/efi in /etc/fstab does not change anything for me
That’s good.
Are other OS’es installed on this system? If so, which one?
Do I undestand this correctly? The system booted fine after the initial upgrade from f42 to f43, but the next update broke it?
Is this session running the rescue kernel? No graphical target?
What does modinfo vfat | head -15 do?
try
modprobe vfat
lsmod |grep vfat
mount /boot/efi
# if that fails then try
mount /dev/nvme0n1p1 /boot/efi
#if successful
ls -l /boot/efi/ /boot/efi/EFI/ /boot/efi/EFI/fedora/
cat /boot/efi/EFI/fedora/grub.cfg
What kernel version does the rescue kernel have?
file /boot/vmlinuz-0-rescue-*
try to boot the newest kernel w/o the option rhgb and upload a screenshot where/ how it fails.
I only have Fedora on the system, though I noticed the existence of “opensuse-secureboot” in the boot order of my UEFI, which I guess are the “remains” of my previous install of OpenSUSE Tumbleweed. Could that cause problems?
Not exactly the next, but probably the second or third after the upgrade to 43. I also disabled the option “reboot after updates” in Discover, which I won’t do again…
Indeed.
All the commands you suggested returned “module vfat not found” or “unknown filesystem type ‘vfat’, dmesg may have more information.”
It was not noted on the file you indicated, but running uname returned the kernel version 6.14.0-63.fc42.x86_64.
Even without the rhgb option, I can’t really see where it fails because I just see systemd processing for a very short time before it freezes on a black screen, I saw that the last process on systemd was plymouth, though.
ok i think the vfat issue affects only the outdated rescue kernel.
It seems you see a bug introduced with the rollout of kde 6.5.1.
Boot the newest kernel, remove rhgb quiet and add
systemd.unit=multi-user.target to the linux cmdline.
I expect the system to start to a login prompt.
Then log in and check whether network is available to update the system
sudo dnf clean all
sudo dnf upgrade -x kernel\*
sudo dnf upgrade kwin\* --enable-repo=updates-testing
restart the system. It should now boot into graphical.target. If not, then try to switch to a console with CTRLALTF4 to get access to the system.
If everything is up and running update the rescue kernel
sudo rm /boot/*rescue*
sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"
then run updates again to check for newer kernel
sudo dnf upgrade
It worked, thank you so much !
I wonder what exactly caused the issue, so that I can try to prevent it in the future. If that’s a bug with Fedora itself, should I report it elsewhere?
Thanks again for having given up your time to solve this, it’s a relief to see that I won’t have to reinstall my system.
bad luck! 
The kwin update had a bug.
quoting the changelog for the installed kwin version:
> * Sun Nov 02 2025 Neal Gompa <ngompa@fedoraproject.org> - 6.5.1-2
> - Add patch to make kwin retry when drm device is initially not ready
Thank you for the feedback. Seems there is a solution for F43 and the kwin update should be pushed to stable asap.
sudo efibootmgr to list the uefi boot entries. Delete unneeded boot entries
with the option -b <xxxx> -B. see man efibootmgr
Then also check in /boot/efi/EFI for stale opensuse boot loaders, unless disk was wiped before installing fedora.
yeah, my mistake, I botched the command. Should have been file ... instead of boot ....
rescue kernel: it would not start because the modules in /lib/modules/ were not available anymore. Keep the rescue kernel updated and in sync with one of the available kernels. We would need to force load the kernel modules included in the initramfs. I assumed that this was the case.
Got it, thanks for everything!