Cannot boot into installation media or installed Fedora system on Dell XPS 16 9640 after BIOS update

Hello everyone,

I have a Dell XPS 16 9640 computer with Fedora 41 Workstation installed. After updating the BIOS to version 1.12.0, I can’t boot into Fedora anymore. Choosing any option from the GRUB menu the computer freezes to a black screen with just an underscore. I don’t get any output or error messages.

I tried booting into a live media using the Fedora 41 ISO but it leads to the same problem. I also tried with the Fedora 42 Beta and the latest nightly build, all resulting in the same problem.

I have also tried the following:

  • Disabling or enabling Secure Boot.
  • Removing the quiet option from the boot parameters.

I would normally try to downgrade the BIOS, unfortunately Dell does not allow you to downgrade due to security updates and important fixes, so I can’t return to the previous BIOS version.

Additionally, I tried booting into a live media for other distributions. Ubuntu boots just fine, as well as Arch Linux and OpenSuse. But other distros like CentOS and Rocky Linux fail in the same way as Fedora.

I’m happy to provide more information if someone could help me figure out how to get some output.

Thank you in advance! :grinning_face_with_smiling_eyes:

Run efibootmgr in a terminal from the newest live media that boots (you may need to install efibootmgr in the live environment). Post the output (as pre-formatted text using the </> button) together with the contents of /etc/fstab from the Fedora root partition.

1 Like

I’d try CMOS resetting from power button hold (reboot to a BIOS or boot menu, hold power button 25 secs or until chassis lights flash, then reconf BIOS when prompted).

Dell BIOS should auto-find a GRUB EFI from a reset state; that should boot Fedora, and on next reboot after that should be changed to shim/Fedora.

Here is the output for efibootmgr:

BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0002,0003,0000,0001,0004
Boot0000* UEFI PC SN810 NVMe WDC 1024GB 24103J804275 1	HD(1,GPT,06eea835-cdaf-456e-84c8-64720a5bfd9c,0x800,0x219800)/File(\EFI\Boot\BootX64.efi){auto_created_boot_option}
Boot0001* USB NIC (IPV4)	PciRoot(0x0)/Pci(0xd,0x0)/USB(2,0)/USB(3,0)/USB(3,0)/MAC(109819eab4c0,0)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0002* Fedora	HD(2,GPT,c16424e0-ff65-4961-a244-5afa171d24f6,0x463120,0xf000)/File(\EFI\fedora\shimx64.efi)
Boot0003* Ubuntu	HD(1,GPT,06eea835-cdaf-456e-84c8-64720a5bfd9c,0x800,0x219800)/File(\EFI\ubuntu\shimx64.efi)
Boot0004* USB NIC (IPV6)	PciRoot(0x0)/Pci(0xd,0x0)/USB(2,0)/USB(3,0)/USB(3,0)/MAC(109819eab4c0,0)/IPv6([::]:<->[::]:,0,0){auto_created_boot_option}

I had to erase the Fedora installation and installed Ubuntu in the meantime since i needed to use my computer, so no fstab from Fedora. :confused: Not sure what is the lingering Boot0002* Fedora thing in the efibootmgr output.

I did try this a couple times to no avail. And I’m still unable to boot into a live environment

Unfortunately, the 1.12.0 and 1.13.0 versions of the XPS 16 9640 BIOS have caused an incompatibility with the kernel(s) used in F41 and F42. Cf.

So far, I’ve been unable to resolve this as well. I guess a downgrade to BIOS 1.11.1 would help, but Dell have helpfully blocked the downgrade path for security reasons…

1 Like

Some additional links:

We have made some progress on this issue in the Bugzilla discussion. Still haven’t identified precisely where the bug lies, but we have a kernel built using OpenSUSE parameters that is able to boot on the affected machines.

In particular I find that I’m consistently able to boot this set of kernel packages on my XPS 9640 with the 1.13.0 BIOS if I add the kernel boot argument modprobe.blacklist=dell-wmi-ddv. I also find that adding nomodeset seems to help my machine boot more consistently for reasons that I believe are unrelated to the BIOS issue.

I’ve built a live image / installer ISO using these kernel packages since my machine didn’t have an existing Fedora installation. I’ve uploaded the ISO to Google Drive here:

The file size is 2,388,236,288 bytes and its SHA256 digest is 5a1a226518548d419a1a74feb6185fcf10539f515d89bbae5dc5d92c0478f7ea.

To boot with this image, you need to use the e key on the top GRUB entry to edit the kernel boot parameters to end with:

rd.live.image nomodeset modprobe.blacklist=dell-wmi-ddv

If you run the installer, the installed OS will be populated with the custom kernel packages, but you’ll still need to edit the relevant kernel parameters every time you start up in order to be able to boot consistently. (I find that without the blacklist setting, my machine successfully boots about 50% of the time.)

(For the record, to create the image, I followed these general instructions: Livemedia-creator- How to create and use a Live CD - Fedora Project Wiki, with a customized kickstart file and file:/// repo to provide and install the custom kernel RPMs.)

1 Like

It looks like we’ve identified the low-level source of the bug, and I’ve developed a kernel patch that appears to work around it. Here’s a new live image / installer ISO that includes a “pkfix1” kernel that reliably boots on my XPS 9640 without any hacks needed:

The file size is 2,386,515,968 bytes and its SHA256 digest is 229597d2c166a7061f0073e4c0b6e2f83ee160d7c504424e66db3f02ff286485. If you trust me to build you a kernel and OS installer that don’t contain any backdoors, you can give it a try.

I tried your ISO and it booted. I dual boot with Windows and had a / BTRFS, SWAP, & /boot/efi partitions. After installation I just had Windows and UEFI firmware settings available. Same thing happened with your last ISO.

Hmm. If the system is able to boot at all, I think it must be some installer issue unrelated to the custom build — the kernel patch really ought to be the only difference between this ISO and the standard F42 Workstation installer, and all of the infrastructure that comes up with the list of boot options is very agnostic as to the details of the available kernels. I think my best advice has to be very generic: try looking into whether anyone else has run into this phenomenon before?

It might be useful to boot the pkfix1 installer USB to get the efibootmgr output.

Output of efibootmgr command from the ISO requested on my Alienware M16r2 laptop.

BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0006,0005,0000,0001,0002,0003,0004
Boot0000* UEFI USB SanDisk 3.2Gen1 00023004122624100251 PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/HD(2,GPT,e7187656-96af-4c11-a522-4a4a4cfbc3bd,0x1d1dffd8,0x10000)/\EFI\Boot\BootX64.efi{auto_created_boot_option}
Boot0001* UEFI 3500 Micron 1024GB 240346A27560 1 HD(1,GPT,93431f70-046a-4b45-8537-9da084633903,0x800,0x201800)/\EFI\Boot\BootX64.efi{auto_created_boot_option}
Boot0002* ONBOARD NIC (IPV4) PciRoot(0x0)/Pci(0x1c,0x6)/Pci(0x0,0x0)/MAC(1098193eab1a,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option}
Boot0003* ONBOARD NIC (IPV6) PciRoot(0x0)/Pci(0x1c,0x6)/Pci(0x0,0x0)/MAC(1098193eab1a,0)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option}
Boot0004* UEFI HTTPs Boot (MAC:1098193EAB1A) PciRoot(0x0)/Pci(0x1c,0x6)/Pci(0x0,0x0)/MAC(1098193eab1a,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
Boot0005* Windows PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-A0-75-01-46-A2-75-60)/HD(1,GPT,93431f70-046a-4b45-8537-9da084633903,0x800,0x201800)/\EFI\Microsoft\Boot\bootmgfw.efi
Boot0006* Fedora PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-A0-75-01-46-A2-75-60)/HD(1,GPT,93431f70-046a-4b45-8537-9da084633903,0x800,0x201800)/\EFI\fedora\grubx64.efi

Maybe you don’t have free space on the boot partition.

I had a problem like that when I used dual boot and had 100 MB for the boot partition.

When I only use Fedora I didn’t have that problem.
In order not to change the partition, you have to copy the exe file with the current BIOS from the DELL website to a pendrive and install it manually in the BIOS.

Linux won’t log in to the desktop if the boot partitions are full.
try reinstalling the system, you can try increasing these partitions. DELL works very well with Linux..

I deleted some of the old distros on the /boot drive. I’ll reinstall it and let you know if it’s fixed or not.

Hey Peter, this Kernel boots fine and I injected it into my running Fedora (after I used an Ubuntu Kernel for some time…). But where can I find the RPMs of this Kernel and especially the kernel-devel package, needed to compile modules for this kernel?

As reported on the Bugzilla bug, Dell has released a BIOS version 1.14.2 which fixes the issue (as I could just confirm).

Deleting old boot files actually fixed it.

1 Like