Red Hat Bugzilla – Bug 1413191
Update fedora 25 breaks UEFI - MOK - drive cant boot
Last modified: 2017-06-14 21:36:11 EDT
Description of problem:
Updating a clean install of Fedora 25 workstation, with secure boot enabled all time, break the shim stuff.
I get a MOK screen, where i have tried all .efi files in the efi device.
I never get the system to boot at all, i get MOK screen and then BIOS.
dosfsck says .efi files is damaged, and i tried to let it fix it and rebooted, without luck.
In MOK screen, loading the grubx64.efi reported a "corrupted volume"
Version-Release number of selected component (if applicable):
I did a clean install, rebooted servel times, and then i did a
"sudo dnf update" and aprox. 1000 packages got installed, including a new kernel
Then i did a reboot, a power off-on, still getting the MOK -> BIOS screens.
I did it all 2 times, with exactly the same problem.
Installs went fine, but update broke it all.
3th time without secure boot, was without any problems.
Steps to Reproduce:
1. Install Fedora 25 with secure boot on
2. sudo dnf update
Alive and kicking computer
Using M.2 Intel Pro 6000p 128gb as boot drive.
motherboard - Asus Z170I PRO GAMING WIFI - Mini ITX
Am seeing same results with Intel NUC6i5SYK and Intel SSD600p 256gb M.2 PCIe as boot drive.
Steps to reproduce:
1. Install Fedora 25 from live USB stick.
2. Run the Software Updater and let it "Reboot and Install" all of the packages it deems in need of update.
3. Wait for the update to finish and reboot again automatically at end of update installation.
Always boots into MOK management after updates are installed. Selecting to continue the boot at any point after that (either directly or after trying to enroll keys/hash) returns message that no boot device can be found. This happens whether Secure Boot is enabled or disabled in the UEFI bios.
If I stop at step 1 and never run the software update, I can shut down and reboot as often as I like without this happening.
Getting the same results on a Dell Precision 5510 with Intel SSD600p as well. I follow the same steps to reproduce. I can successfully reboot and install software before running dnf update. After dnf update, boot to mok manger.
Getting the same results on a Acer Swift 3 (intel SSDPEKKW256G7).
After install all ok. After dnf update system goes to MokManager.
I seem to be running into the same issue.
System: Intel i5-7600 + ASRock H270ac/n motherboard + Intel 6-series NVME SSD.
Installed Fedora with default partition settings.
Original installation uses grub* packages with fc24 suffix (grub-efi, grub, grub-tools). These install and work properly.
Updating these packages to version 2.02-0.38.fc25 breaks the system.
The boot process reports corrupt \BOOT\EFI\fedora\grubx64.efi file.
Current workaround: running dnf upgrade -x 'grub*' to exclude these packages from the upgrade.
Had the same problem with Intel 600p nvme ssd, switched to Samsung 960 EVO and it worked fine.
In case of Intel SSD this ticket tracks a fs corruption issue caused by a bug in firmware: https://bugzilla.redhat.com/show_bug.cgi?id=1402533
Hit hard with this on my custom Ryzen 1700 build with Intel 600p 256GB NVMe, my EFI partition is corrupt and boot loading randomly crashes and misbehaves (not booting, black screens), this was hard to track down. Terrible experience, thumb down Intel. /CCed
I know that the new 121 FW for the 600p has resolved the following issue for me:
Have you all tried this new FW for this issue? Does the issue still occur? I have not seen this issue, so just wondering
Can everyone that is having trouble confirm the FW revision they're running?
You can do so by grabbing a copy of nvme-cli (it's in packages) or from https://github.com/linux-nvme/nvme-cli
and running (as root) `nvme list` and pasting the output here. I ask because I am currently testing fedora/debian installs on 121 and I can't repro. The issues everyone is having seems similar to bug 1402533 so I want to confirm we're all operating on the same firmware.
The original bug 1402533 still exists in the latest 121C firmware, my Centos VM's corrupted the filesystem within several days after applying 121C FW.
FWIW running ESXi6.0U3 on Intel 600P and all Centos VMs corrupt the superblock within a week. The Windows VMs work fine though.
Raised this issue on the Intel community forums several months ago then found the Redhat bug report. Can't help thinking this is the same issue?
What's your VM setup? Looking to try and repro the issue. Going to try and setup what you have and see if I can get the corruption.
Nothing special, Supermicro X10SDV-TLN4F with Supermicro ECC 64Gb RAM running VMWare ESXi 6.0 U3. This has a multiple HDDs attached: Intel NVMe 60P 512Gb, Crucial MX300 SSD, Western Digital Red 1Tb SATA HDD. I am using Centos 6 & 7 x64 OS VMs. In February I moved the Centos 7 x64 VMs onto the Intel 600P and they ran very well! But within 7 days this started corrupting them so they have been moved back to the Crucial SSD HDD and they have been running OK since then. Interestingly the sole Windows 10 VM continues to run OK on the Intel 600P.
FWIW - ESXi boots from the Intel 600P and runs well. FWIW I also installed Centos plus Docker in February and this died the same way. The VMs are configured with VMware paravirtual or LSI controller, makes no difference.
I think the 121C firmware is improved, the new Centos VM I made last week is still running. But the Centos VM running Graylog died within 4 days.
Note that you need to reboot the VMs to test if the filesystem is corrupt
Still happens with a Dell Vostro 3700