I have a dual boot Alienware m16 R10 laptop on which Windows kindly updated the bios to version 1.10.0. This has caused Fedora not to boot. The fedora choice in grub is still available and I’ve tried adding “nomodeset and acpi=off” but to no avail.
There appears no way to downgrade the bios to the previous version as this has been blocked by Dell.
Currently the machine will boot from a Ubuntu 24.04 live usb stick, but not from either a Fedora 41 Workstation USB stick not a Fedora 42 one. Can anyone suggest a reason for this?
Bitlocker? I think you can turn it off from within Windows.
Can you attempt to boot the Fedora installation and view the relevant parts of journalctl output.
You may need to remove rhgb and quiet flags grub to get some output on screen so you can at least see what the issue is… and then switch to another console to query the log
I tried that, but still only get a post grub blank screen with a non blinking cursor at the top left of the screen. It doesn’t get very far at all into the boot sequence.
I had a similar experience with a Dell system. The Fedora server USB would boot. Previous Windows updates on 2 Dell systems often needed extra work to get Fedora to boot, so I removed Windows on both systems.
1 Like
I’d try a CMOS reset with power button hold for 20 secs (that’s for a 5591 but Alienware might be different).
I also do a USB recovery (BIOS exe renamed on FAT32 and Ctrl + Esc with AC plug-in) and restore BIOS + restore default settings for new versions just to make sure it’s flashed right. Reflashing through USB recovery resets the brightness on battery setting to legit default which has me thinking this resets the BIOS more thoroughly than a CMOS reset.
I just hit this exact problem on my Alienware M16 R2. The previous Fedora rawhide installation no longer boots at all, just a black screen with a non blinking cursor. The same behavior occurs with a LiveUSB of Fedora 41 or 42.
I’ve had a support call open with Dell about this but they have been fairly unhelpful. They’ve offered lots of suggestions, but nothing useful. These are their suggestions:
We have received an update from our resolution expert team,
" unfortunately BIOS downgrade is by default disabled on some of the systems due to security issues, especially when Security update is involved in the firmware update.
We only have 2 options here, from BIOS you can try changing the SATA operation from AHCI to RAID ON or from RAID ON to AHCI (viceversa) or you can try changing the boot path manually. "
"If both the options doesn’t work, then you will have to perform a Clean Windows re-installation and check for downgrade options and then load the dual OS. "
I asked why reinstalling windows would allow Fedora to run…
“Thank you for the email, Performing a format on hard drive may let you to downgrade BIOS to older version.
Also, we do not have much expertize on Fedora, as this is a 3rd party windows, we are unsure about what security feature disabled the Fedora OS.”
Finally they did send this link: DSA-2025-044: Security Update for Dell Client Platform for an EDK2 Vulnerability | Dell UK, which then led to here: Integer overflows in PeCoffLoaderRelocateImage · Advisory · tianocore/edk2 · GitHub
This points to " Integer overflows in PeCoffLoaderRelocateImage " being the main change. Does anyone know how this would affect the kernel used in Fedora?
I’ve tried all the methods of downgrading the BIOS to no avail. This path has been thoroughly blocked by Dell.
I wonder if a Live USB from some other distro that uses journalctl would allow you to view journal entries on the Fedora 41 system. If you have another Fedora system you might be able to use a non-Fedora USB installer to copy the journals from the non-booting system in order to inspect them on another Fedora system. if When my Dell systems wouldn’t boot the Fedora Workstation USB, I was able to boot the Fedora Server USB.
For such experiments, ventoy allows to put a bunch of USB installers on one USB key and choose the one you want to try.
Just foolishly ran windows update yesterday and noticed it did a BIOS update, and lo and behold I now can’t boot fedora either from the installed system or via any of the live USB images either - tried server as well and a few different spins from 41 and 42. Did you get any further with this @jopeno
Edit: Also on an Alienware m16 r2 with BIOS 1.10.0
Edit2: Just tried latest rawhide nightly live image and same issue 
Edit3: I see Dell have released 1.11.0 with another security update, but am guessing this won’t solve the problem
The 1.11 version didn’t help me. I’ve tried the nightly builds and still nothing. I guess the issue will be solved in time…
I did not know that Windows can update a BIOS is some circumstances. This could be very annoying.
Has it changed some settings? Secure Boot, TPM, Bitlocker??
Currently investigating using an OpenSUSE kernel temporarily to get the fedora 42 installation running after someone else with same system was able to do that: Tom "spot" Callaway :fedora:: "Okay, progress. I put the OpenSUSE kernel (6.14.1…" - A Social Front Organization
Looks like it’s reported here but not sure where else it needs reporting, perhaps fedora linux kernel maintainers?
Am wondering whether attempting to compile my own kernel will solve it too, although I’ve not done that for many years!
Do you get the grub2 menu or does the system just boot to Windows? I’ve had similar problems with multiple Windows 10 and 11 updates on a couple Dell systems (so longer use Windows). Windows Settings Advanced Startup Options may boot a Live USB to investigate.
grub2 is fine but any fedora live image immediately hangs after grub2 menu, other distros boot fine - so seems specific to the fedora kernel and 1.10.0 and 1.11.0 BIOS versions. not possible to roll back to 1.9.0 BIOS because Dell’s system prevents that as 1.10.0 was a security fix
@jopeno I was able to make this work - used an OpenSUSE live usb to then chroot into fedora after opening the encrypted luks partition, installed OpenSUSE kernel from their .rpm, manually copied some files and edited entries and then was able to boot into fedora using that kernel!
I also tried vanilla fedora kernels from both the stable and mainline options on copr but those had the same problem as the normal fedora kernel. Now I have a booting system using OpenSUSE’s kernel, next step is investigating building a fedora kernel from source and seeing what differences there are on the configs for fedora and opensuse since there must be something in there that’s not compatible with what Dell have done with their BIOS update!
That’s great progress, let us know if you get any further. Thanks for your efforts.
Not sure I’ll be able to progress any further, there are thousands of kernel config options and comparing the configs of suse and fedora there are lots of differences. So I wouldn’t really know where to begin to know which config option is involved with the dell bios. Hopefully the fedora kernel team will pick up on it? I’ve seen dell XPS users having the same problem.
Since the issue seesm to prevent booting https://docs.kernel.org/trace/boottime-trace.html seems like the place to start.
It might be more useful to compare config files for a Fedora kernel that boots with one that fails.
The Fedora config file is organized in blocks (unfortunately, block headers are not consistent, and some lack headers. Most are like:
#
# NAME
#
....
# end of NAME
If SUSE use the same structure you can try swapping one block at a time, starting with ones that changed between Fedora working and broken kernels.