Upgrading working F23 install to F24 using the Live ISO. The anaconda installer seems to run just fine (twice) and apparently exceeds at installing F24. However I see this message when the F24 Kernel boots. - error: symbol 'grub_efi_secure_boot' not found The PC fails to boot into Fedora and the machine is stuck in Grub. How reproducible: On this particular machine, this 'grub_efi_secure_boot' not found message occurs after each and every F24 live install. The machine's BIOS does not support UEFI booting. Could this be contributing to the problem? Steps to Reproduce: 1. Boot to F24 Live Iso 2. Install F24 to partitions 3. Reboot after install completes and bam the error occurs. Actual results: F24 install fails to boot. Expected results: A bootable F24 system. Additional info: This FPASTE URL : - https://paste.fedoraproject.org/384319/14668001/ documents the output from these commands: - lsblk -af ; efibootmgr ; mokutil --sb-state > /tmp/myefi.txt
Moving to grub2 component...
I had a similar instance happen to me after upgrading the windows side of my dual-boot. I was previously on Fedora 23 before I upgraded that to 24 and duel-booted it with Windows 10. Then I grabbed the Anniversary update for Windows 10, which caused this to happen. Honestly, I am a little lost on how to repair the system short of a reinstall... but if I am reading this right, that might not help. That said, I think that there might be a way to fix this without reinstalling the system since grub is still on the system, and nothing in my partitions seem to be affected. Would you happen to have any suggested to help troubleshoot this?
I suffered this same error message on three ISO installs of F24 on three different machines. - Hand built workstation - MSI Laptop - System 76 Laptop The work around I discovered was this. Re-install F23 on all machines taking care not to install third party repos. The F23 installer creates bootable systems on all my machines in question! Then upgrade F23 -> F24 using the dnf upgrade plugin. On each machine I was able to boot F24 successfully without the error. Given the repeat-ability of the error (on my machines) and the fact that F23 does NOT suffer from this problem. I believe this is a serious problem that needs to be worked out. Thank you, Rob
(In reply to Rob Seward from comment #3) > I suffered this same error message on three ISO installs of F24 on three > different machines. > > - Hand built workstation > - MSI Laptop > - System 76 Laptop > > The work around I discovered was this. > > Re-install F23 on all machines taking care not to install third party repos. > The F23 installer creates bootable systems on all my machines in question! > > Then upgrade F23 -> F24 using the dnf upgrade plugin. > > On each machine I was able to boot F24 successfully without the error. > > Given the repeat-ability of the error (on my machines) and the fact that F23 > does NOT suffer from this problem. I believe this is a serious problem that > needs to be worked out. > > Thank you, > Rob Rob, I am wondering... did you ever test with the Fedora respins? http://tinyurl.com/Live-respins2 Th
(In reply to Rob Seward from comment #3) > I suffered this same error message on three ISO installs of F24 on three > different machines. > > - Hand built workstation > - MSI Laptop > - System 76 Laptop > > The work around I discovered was this. > > Re-install F23 on all machines taking care not to install third party repos. > The F23 installer creates bootable systems on all my machines in question! > > Then upgrade F23 -> F24 using the dnf upgrade plugin. > > On each machine I was able to boot F24 successfully without the error. > > Given the repeat-ability of the error (on my machines) and the fact that F23 > does NOT suffer from this problem. I believe this is a serious problem that > needs to be worked out. > > Thank you, > Rob Rob, I am wondering... did you ever test with the Fedora respins? http://tinyurl.com/Live-respins2 That might happen to solve some problems, since it does update some of the components that would be on the install media. Sorry for the double post.
(In reply to DuvJones from comment #5) > (In reply to Rob Seward from comment #3) > > I suffered this same error message on three ISO installs of F24 on three > > different machines. > > > > - Hand built workstation > > - MSI Laptop > > - System 76 Laptop > > > > The work around I discovered was this. > > > > Re-install F23 on all machines taking care not to install third party repos. > > The F23 installer creates bootable systems on all my machines in question! > > > > Then upgrade F23 -> F24 using the dnf upgrade plugin. > > > > On each machine I was able to boot F24 successfully without the error. > > > > Given the repeat-ability of the error (on my machines) and the fact that F23 > > does NOT suffer from this problem. I believe this is a serious problem that > > needs to be worked out. > > > > Thank you, > > Rob > > Rob, I am wondering... did you ever test with the Fedora respins? > http://tinyurl.com/Live-respins2 > That might happen to solve some problems, since it does update some of the > components that would be on the install media. > > Sorry for the double post. No I have not. Do you have a respin you recommend? Thanks, Rob
(In reply to Rob Seward from comment #6) > > No I have not. Do you have a respin you recommend? > > Thanks, > Rob I am not really sure on which one I would suggest. I simply snagged the Live-Workstation (since I really like Gnome 3) respin and installed the system from there. It's been smooth, reinstalled from the respin without any issue. My system has been back to normal since. I would assume that it would be similar with XFCE, Cinnamon, MATE or KDE.
You know, I have reason to wonder if this has anything to do with the "golden key" flub up... I doubt it is related, but it happened around the same time as Anniversary Update. And I have been running on Fedora 24 GA fine since.
I encountered this error when I upgraded fedora 23 to 24 (using dnf like you did) yesterday on a physical HP desktop PC (dx7300) with a multi-OS setup including two bootable hard drives having grub2 installed on them. I did a 23-24 upgrade using the same process today on a virtual machine that only has one virtual disk, and did not encounter the error. After reading https://utcc.utoronto.ca/~cks/space/blog/linux/GrubDiskMismatchError, where Chris outlined his struggle with this same upgrade and problem, finding that for him it was a BIOS boot order issue, I thought it would be worth a try to change the boot order in the BIOS of the machine with the grub error. It worked, so I thought it would be useful feedback to include here. It appears that grub was reinstalled/upgraded on the boot sector of the HDD that was second on the boot order in the BIOS, rather than the first, since switching first boot in the BIOS to that drive fixed the problem for me.
I have the same problem with a HP desktop (probably a dc5700 or dc5800), single disk, single OS. Started with or after dnf upgrading to f24. Over the weekend I remotely updated to kernel-4.7.2-201 and the machine is now stuck at that grub error. I think this is the second time this happens, not sure what I did last time to recover, but hopefully will be able to do the same tomorrow when I go to the office.
Booted from a F24 Live USB, but that couldn't mount my linux system. Dropped to a shell, mounted it manually, chroot, grub2-install and that fixed it. Not sure how I got into this situation, maybe the kernel update did it. I'll check it when the next kernel comes along.
(In reply to Rob Seward from comment #6) > (In reply to DuvJones from comment #5) > > (In reply to Rob Seward from comment #3) > > > I suffered this same error message on three ISO installs of F24 on three > > > different machines. > > > > > > - Hand built workstation > > > - MSI Laptop > > > - System 76 Laptop > > > > > > The work around I discovered was this. > > > > > > Re-install F23 on all machines taking care not to install third party repos. > > > The F23 installer creates bootable systems on all my machines in question! > > > > > > Then upgrade F23 -> F24 using the dnf upgrade plugin. > > > > > > On each machine I was able to boot F24 successfully without the error. > > > > > > Given the repeat-ability of the error (on my machines) and the fact that F23 > > > does NOT suffer from this problem. I believe this is a serious problem that > > > needs to be worked out. > > > > > > Thank you, > > > Rob > > > > Rob, I am wondering... did you ever test with the Fedora respins? > > http://tinyurl.com/Live-respins2 > > That might happen to solve some problems, since it does update some of the > > components that would be on the install media. > > > > Sorry for the double post. > > No I have not. Do you have a respin you recommend? > > Thanks, > Rob I encountered this error using the Fedora 24 MATE/Compiz spin. I installed it via live USB, and saw the same behavior as the OP. Installing F23 MATE/Compiz from scratch did indeed fix the problem, but I have not yet tried the dnf upgrade to F24 as mentioned above. I need my system to be stable for a few days, but I'll try the dnf upgrade when I can. Also, I tried disabling secure boot in my BIOS, but that seemed to have no effect. Thanks, Kyle
I've also encountered this problem. Resolved by changing hard drive boot priority in the BIOS. It seems that an old grub was still installed on a disk that was picked by BIOS for boot up.
Encountered the same problem after installing Fedora 25 (over instalation of Fedora 23). I practice fresh installation where I keep /home (and /data on a separate disk) filesystems untouched and just reformat swap /boot and / filesystems. This has worked flawlessly until now. After reading various advises on how to work around this problem, which didn't work, I read the following post: https://utcc.utoronto.ca/~cks/space/blog/linux/GrubDiskMismatchError ...which made me check by BIOS settings. The hardware is a Lenovo ThinkCenter PC and I have 2 SATA disks attached: an SSD disk which was reported by BIOS to be attached to SATA 1 port and a HD which was reported to be connected to SATA 2 port. The boot order in BIOS was set to: 1st SSD, 2nd HD. Fedora 23 was installed to have /boot on a primary msdos partition of SSD, / and /home were on a LVM2 group on SSD and /data on LVM2 group on HD. The strange thing that caught my eye was that while SSD is reported by BIOS to be connected to SATA 1 port, it is assigned device /dev/sdb in Linux, while HD which is reported by BIOS to be on SATA 2 port is assigned device /dev/sda on Linux. All of above hasn't changed when I installed Fedora 25 by reformatting swap /boot and / filesystemsm, but I couldn't boot any more. What I finally did to make a bootable system was to physically swap SATA connectors of SSD and HD. SSD is now reported to be connected to SATA 2 port, HD to SATA 1 port, while Linux assigns SSD to /dev/sda and HD to /dev/sdb. I had to change the boot order in BIOS to keep 1st SSD as it was automatically moved to 2nd place by swapping the cables. I reinstalled Fedora 25 and it now boots! Just another note: While the bug mentions grub_efi_secure_boot, the booting method I use is the legacy booting method, not EFI. I have EFI method disabled in BIOS. One of my unsuccessful attempts at making a bootable system before swapping disks was to enable EFI booting method and disable legacy. Anaconda installer didn't want to accept my configuration although I created /boot and /boot/efi as separate partitions. It kept complaining that there is no /boot/efi GPT partition. Perhaps my SSD disk is using MBR partitions? But shouldnt EFI be compatible with MBR partitions too?
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.