Description of problem: Fedora 30 only boot after the installation (kernel 5.0.9-301), but stops booting after the update (kernels 5.1.7-300, 5.1.12-300, 5.1.15-300). In the last case, it appears "EFI stub: UEFI Secure Boot is enabled." and gets stuck. Version-Release number of selected component (if applicable): How reproducible: all the times Steps to Reproduce: 1. Install Fedora 30 on ASUS VivoBook S14 2. sudo dnf update --refresh 3. Reboot Actual results: It appears "EFI stub: UEFI Secure Boot is enabled." and gets stuck Expected results: The system boots Additional info: Solution: sudo grubby --update-kernel=ALL--args="dis_ucode_ldr"
(In reply to fedeli.vale from comment #0) > Description of problem: > Fedora 30 only boot after the installation (kernel 5.0.9-301), but stops > booting after the update (kernels 5.1.7-300, 5.1.12-300, 5.1.15-300). In the > last case, it appears "EFI stub: UEFI Secure Boot is enabled." and gets > stuck. > > > Version-Release number of selected component (if applicable): > > > How reproducible: all the times > > > Steps to Reproduce: > 1. Install Fedora 30 on ASUS VivoBook S14 > 2. sudo dnf update --refresh > 3. Reboot > > Actual results: > It appears "EFI stub: UEFI Secure Boot is enabled." and gets stuck > > Expected results: > The system boots > > > Additional info: > Solution: sudo grubby --update-kernel=ALL--args="dis_ucode_ldr" I suffered from the very same issue with the same symptoms etc. The only difference was the laptop - ASUS ZenBook UX433FN, in my case. Yesterday, I updated the BIOS (from version 301 to 305) and it seems to resolve this issue for me. I was able to boot kernels 5.1.12-300 and 5.1.15-300 several times in a row without the "dis_ucode_ldr" argument. Could you please try updating your BIOS to see if it helps?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
Hi, Same issue here with last update. This problem isn't related to the kernel version but to the intel microcode update. For reference : https://ask.fedoraproject.org/t/fedora-new-kernel-not-working-after-dnf-upgrade-refresh/2222 There is also a issue in the intel microcode repository : https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 For now the only working solution is to run this command after each kernel update : sudo grubby --update-kernel=ALL--args="dis_ucode_ldr"
Thanks for the update, reassigning to microcode_ctl.
Np :-) I still have one question, the problem was to load the intel microcode , someone can explain my why I have this behavior : - Boot on kernel 5.0.9-301 work ( Grub -> Kernel load -> Passphrase for encrypted -> Boot ) - With all the newest kernel ( 5.1.18 , 5.2.7 , 5.2.8 , 5.2.9 ) doesn't work ( Grub -> Black screen -> force reboot ) . The only way to boot with theses kernel is to add the "dis_ucode_ldr" option with grubby or on Grub edit. If the microcode intel was present in the package : microcode_ctl-2.1-30.fc30.x86_64 why is it working with previous kernel ? Thanks for the help ;-)
Because it gets brought into the initramfs. When a kernel is installed, the initramfs is generated, which includes the microcode present on the system at install time. This doesn't get updated when you install a new microcode_ctl.
More information : After a BIOS update ( as mentioned in the related bug report ) I don't have a black screen, but the message from this initial bug report : EFI stub: UEFI Secure Boot is enabled . I will try to update microcode to the last version and update the kernel to force update in the initramfs . I will keep you informed
Same problem on a Dell Inspiron 3870. Adding "dis_ucode_ldr" doesn't appear to help
Correction: Adding "dis_ucode_ldr" solves the problem. (I was impatient)
It seems, there are other folks with Asus laptops experiencing similar issue: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 Unfortunately it was not resolved yet. I will update the microcode as soon as we have the fix.
Folks, we've got a number of bios updates since the report. Also check new BIOS for your hardware. Hopefully the problem is gone. And if it is not - subscribe and follow this issue at github: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 There is nothing I/we can do with this bug besides waiting for the blob from Intel that fixes the issue.
Hi! I have same issue on my Fedora Worstation 37, but my cpu AMD Ryzen 5 1500X. System hardware: CPU: AMD Ryzen 5 1500X Base Board Information Manufacturer: Micro-Star International Co., Ltd Product Name: B350M PRO-VDH (MS-7A38) Version: 2.0 Serial Number: H316702977 Asset Tag: To be filled by O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To be filled by O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 The problem has begun after update kernel on 6.1.18 and is still preserved I flash my BIOS on last firmware, but it not helped me.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days