Hello there,
Dell XPS-15-9560 laptop (SSD drive, UEFI, secure boot off).. Windows 10 pre-installed, CentOS7 installed in a separate partition and running for months w/o issue. Don't know what happened but at reboot yesterday (not even booted in Windows, just rebooted), grub has disappeared, booted in Windows by default, which apparently has taken over the UEFI boot.
By booting from a USB drive w/ CentOS7 LiveGnome, I could use its grub command prompt to inspect the UEFI of the local SSD drive, see that the centos/ sub-directory and files are still there.
/boot/efi/EFI/centos/: BOOT.CSV BOOTX64.CSV fonts grub.cfg grub.cfg.1501243846.rpmsave grub.cfg.1505469290.rpmsave grubenv grubx64.efi mmx64.efi shim.efi shimx64-centos.efi shimx64.efi
maybe /boot/efi/EFI/Boot/ contents has been altered?
/boot/efi/EFI/Boot/: bootx64.efi fbx64.efi
I had a backup of the full efi partition (`dd`) but it's outdated and I feel it's a bad idea to restore the partition from it.
Still from this "external" grub prompt, I could boot into my CentOS7 using: configfile (hd0,gpt1)/EFI/centos/grub.cfg
At least I know how to get back to it :-).
But now, how could I give the UEFI control back to grub? Is there a grub2 or grubby command I can run to make grub the default? I've read a lot and still cannot figure out exactly what to do or don't dare running commands that could make things worse.
And I have the feeling the at next Windows boot, I may need to do it again..
Regards,
You can to use efibootmgr for this. NVRAM boot entry is what changed, not the contents of the EFI System partition.
efibootmgr -v
Will list all entries and Boot Order. You need to use --bootorder to make sure the CentOS entry is first.
Chris Murphy
Hello Chris,
On Thu, 01 Feb 2018 17:00:03 +0000 Chris Murphy lists@colorremedies.com wrote:
You can to use efibootmgr for this. NVRAM boot entry is what changed, not the contents of the EFI System partition.
efibootmgr -v
Will list all entries and Boot Order. You need to use --bootorder to make sure the CentOS entry is first.
Interesting.. thanks for your reply!
Too bad I never run this command when things were OK (in order to compare), 'cause now, what it says doesn't mention anything that seem related to the CentOS partition or I read wrong:
BootCurrent: 0007 Timeout: 0 seconds BootOrder: 0001,0002,0003,0004,0005,0006,0007 Boot0000* Windows Boot Manager HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}.................... Boot0001* UEFI: A400 NVMe SanDisk 512GB, Partition 1 HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO Boot0002* Diskette Drive BBS(Floppy,Diskette Drive,0x0)..BO Boot0003* M.2 PCIe SSD BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO Boot0004* USB Storage Device BBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO Boot0005* CD/DVD/CD-RW Drive BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO Boot0006* Onboard NIC BBS(Network,Onboard NIC,0x0)..BO Boot0007* UEFI: KingstonDataTraveler 3.0PMAP, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/HD(1,MBR,0x61f11812,0x800,0x737f800)..BO
I don't know what 0001 and 0002 refer to exactly (there's only one SSD drive in this laptop).
Regards,
On Thu, Feb 1, 2018 at 10:13 AM, wwp subscript@free.fr wrote:
Hello Chris,
On Thu, 01 Feb 2018 17:00:03 +0000 Chris Murphy lists@colorremedies.com wrote:
You can to use efibootmgr for this. NVRAM boot entry is what changed, not the contents of the EFI System partition.
efibootmgr -v
Will list all entries and Boot Order. You need to use --bootorder to make sure the CentOS entry is first.
Interesting.. thanks for your reply!
Too bad I never run this command when things were OK (in order to compare), 'cause now, what it says doesn't mention anything that seem related to the CentOS partition or I read wrong:
BootCurrent: 0007 Timeout: 0 seconds BootOrder: 0001,0002,0003,0004,0005,0006,0007 Boot0000* Windows Boot Manager HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}.................... Boot0001* UEFI: A400 NVMe SanDisk 512GB, Partition 1 HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO Boot0002* Diskette Drive BBS(Floppy,Diskette Drive,0x0)..BO Boot0003* M.2 PCIe SSD BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO Boot0004* USB Storage Device BBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO Boot0005* CD/DVD/CD-RW Drive BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO Boot0006* Onboard NIC BBS(Network,Onboard NIC,0x0)..BO Boot0007* UEFI: KingstonDataTraveler 3.0PMAP, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/HD(1,MBR,0x61f11812,0x800,0x737f800)..BO
I don't know what 0001 and 0002 refer to exactly (there's only one SSD drive in this laptop).
For whatever reason the CentOS entry is missing.
Option 1:
A relatively easy cheat is to mount your root volume to /mnt and then search
grep efibootmgr /mnt/var/log/anaconda/program.log ##this is the path and name on Fedora, not 100% certain on CentOS
And what you'll get back is a line that contains the efibootmgr command that was used during the installation. So you'll need to modify the forward slashes for it to work, something like this:
sudo efibootmgr -c -w -L CentOS -d /dev/sda -p 2 -l \EFI\redhat\grub\shimx64.efi
Option 2:
At least on Fedora 27 + Windows 10, this is what my ESP contains:
├── EFI │ ├── Boot │ │ ├── bootx64.efi │ │ ├── fallback.efi │ │ └── fbx64.efi
Those are Fedora installed default bootloaders. So if you wipe out all the NVRAM boot entries, these get used first. And when fallback.efi figures out that there isn't a proper NVRAM boot entry, it's supposed to insert one, just like the Option 1 command above does. You'll use 'efibootmgr -b XXXX -B' to delete them one by one; looks like you might be able to get away with just deleting 0001 and 0000. Of course it means the Windows boot entry is blown away, which might make you nervous - but the way it's supposed to work is the GRUB menu should have a Windows boot option in it, and you just pick that for booting Windows.
I've mainly used option 1.
Hello Chris,
On Thu, 1 Feb 2018 13:25:14 -0700 Chris Murphy lists@colorremedies.com wrote:
On Thu, Feb 1, 2018 at 10:13 AM, wwp subscript@free.fr wrote:
Hello Chris,
On Thu, 01 Feb 2018 17:00:03 +0000 Chris Murphy lists@colorremedies.com wrote:
You can to use efibootmgr for this. NVRAM boot entry is what changed, not the contents of the EFI System partition.
efibootmgr -v
Will list all entries and Boot Order. You need to use --bootorder to make sure the CentOS entry is first.
Interesting.. thanks for your reply!
Too bad I never run this command when things were OK (in order to compare), 'cause now, what it says doesn't mention anything that seem related to the CentOS partition or I read wrong:
BootCurrent: 0007 Timeout: 0 seconds BootOrder: 0001,0002,0003,0004,0005,0006,0007 Boot0000* Windows Boot Manager HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}.................... Boot0001* UEFI: A400 NVMe SanDisk 512GB, Partition 1 HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO Boot0002* Diskette Drive BBS(Floppy,Diskette Drive,0x0)..BO Boot0003* M.2 PCIe SSD BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO Boot0004* USB Storage Device BBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO Boot0005* CD/DVD/CD-RW Drive BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO Boot0006* Onboard NIC BBS(Network,Onboard NIC,0x0)..BO Boot0007* UEFI: KingstonDataTraveler 3.0PMAP, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/HD(1,MBR,0x61f11812,0x800,0x737f800)..BO
I don't know what 0001 and 0002 refer to exactly (there's only one SSD drive in this laptop).
For whatever reason the CentOS entry is missing.
I'd like to know the reason (not formally asking here), the 1st time it happened it was because I booted in Windows, which is known to more or less rewrite the boot entries (in case of updates, IIRC), but this time it was not the case, I was attempting to boot a pmagic live USB drive.. UEFI killer? :-/
Option 1:
A relatively easy cheat is to mount your root volume to /mnt and then search
grep efibootmgr /mnt/var/log/anaconda/program.log ##this is the path and name on Fedora, not 100% certain on CentOS
And what you'll get back is a line that contains the efibootmgr command that was used during the installation. So you'll need to modify the forward slashes for it to work, something like this:
sudo efibootmgr -c -w -L CentOS -d /dev/sda -p 2 -l \EFI\redhat\grub\shimx64.efi
Option 2:
At least on Fedora 27 + Windows 10, this is what my ESP contains:
├── EFI │ ├── Boot │ │ ├── bootx64.efi │ │ ├── fallback.efi │ │ └── fbx64.efi
(no fallback.efi here, but I presume fbx64.efi is a fallback too?)
Those are Fedora installed default bootloaders. So if you wipe out all the NVRAM boot entries, these get used first. And when fallback.efi figures out that there isn't a proper NVRAM boot entry, it's supposed to insert one, just like the Option 1 command above does. You'll use 'efibootmgr -b XXXX -B' to delete them one by one; looks like you might be able to get away with just deleting 0001 and 0000. Of course it means the Windows boot entry is blown away, which might make you nervous - but the way it's supposed to work is the GRUB menu should have a Windows boot option in it, and you just pick that for booting Windows.
I've mainly used option 1.
You were right, the initial efibootmgr command was in anaconda's log, I could do, for the sake of the archives:
$ efibootmgr -c -w -L CentOS Linux -d /dev/nvme0n1 -p 1 -l \EFI\centos\shim.efi BootCurrent: 0007 Timeout: 0 seconds BootOrder: 0008,0001,0002,0003,0004,0005,0006,0007 Boot0000* Windows Boot Manager Boot0001* UEFI: A400 NVMe SanDisk 512GB, Partition 1 Boot0002* Diskette Drive Boot0003* M.2 PCIe SSD Boot0004* USB Storage Device Boot0005* CD/DVD/CD-RW Drive Boot0006* Onboard NIC Boot0007* UEFI: KingstonDataTraveler 3.0PMAP, Partition 1 Boot0008* CentOS
And it simply works, I could restart the system and boot from grub (which proposes to boot to Windows too, grub is a good boy).
A huge thanks to you, Chris, I owe you one.
Regards,
On 02/01/2018 12:15 PM, wwp wrote:
Hello there,
Dell XPS-15-9560 laptop (SSD drive, UEFI, secure boot off).. Windows 10 pre-installed, CentOS7 installed in a separate partition and running for months w/o issue. Don't know what happened but at reboot yesterday (not even booted in Windows, just rebooted), grub has disappeared, booted in Windows by default, which apparently has taken over the UEFI boot.
The DELL XPS-13-9360 in its BIOS has an option (named "auto boot recovery" or similar - sorry the machine is somewhere else) that is by default enabled. I guess you have it enabled as well.
This option is triggered by two unsuccessful boot trials, and leads to the loss of the grub menu, and restoration of the (non-grub) "Windows boot manager" (or whatever it's called).
After being bit by it once, I disabled it.
HTH,
Kay
P.S. I recovered my Ubuntu grub menu by booting from the Ubuntu live USB, and then sudo su mount /dev/nvme0n1p7 /mnt cd /mnt mount /dev/nvme0n1p1 boot/efi mount --bind /proc proc mount --bind /sys sys mount --bind /dev dev chroot /mnt grub-install /dev/nvme0n1 update-grub
On CentOS, the last two lines would be
grub2-install /dev/nvme0n1 grub2-mkconfig -o etc/grub2.cfg
By booting from a USB drive w/ CentOS7 LiveGnome, I could use its grub command prompt to inspect the UEFI of the local SSD drive, see that the centos/ sub-directory and files are still there.
/boot/efi/EFI/centos/: BOOT.CSV BOOTX64.CSV fonts grub.cfg grub.cfg.1501243846.rpmsave grub.cfg.1505469290.rpmsave grubenv grubx64.efi mmx64.efi shim.efi shimx64-centos.efi shimx64.efi
maybe /boot/efi/EFI/Boot/ contents has been altered?
/boot/efi/EFI/Boot/: bootx64.efi fbx64.efi
I had a backup of the full efi partition (`dd`) but it's outdated and I feel it's a bad idea to restore the partition from it.
Still from this "external" grub prompt, I could boot into my CentOS7 using: configfile (hd0,gpt1)/EFI/centos/grub.cfg
At least I know how to get back to it :-).
But now, how could I give the UEFI control back to grub? Is there a grub2 or grubby command I can run to make grub the default? I've read a lot and still cannot figure out exactly what to do or don't dare running commands that could make things worse.
And I have the feeling the at next Windows boot, I may need to do it again..
Regards,
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, Feb 5, 2018 at 8:27 AM, Kay Diederichs kay.diederichs@uni-konstanz.de wrote:
grub-install /dev/nvme0n1
Running this on computers with UEFI firmware is not good advice, it's an obsolete command. People should use the prebaked grubx64.efi binary that comes in the grub2-efi package, and is a signed binary so it can support UEFI Secure Boot.
If you run grub2-install, a new unsigned grub binary is created, replacing grubx64.efi. If you have Secure Boot enabled, you will not be able to boot, until you either reinstall the grub2-efi package (or you self-sign the grub2-install created binary and then go through the process of informing the firmware this is a valid binary by using mokutil - but I estimate maybe 1 in 50 people might do this).
On 02/05/2018 09:10 PM, Chris Murphy wrote:
On Mon, Feb 5, 2018 at 8:27 AM, Kay Diederichs kay.diederichs@uni-konstanz.de wrote:
grub-install /dev/nvme0n1
Running this on computers with UEFI firmware is not good advice, it's an obsolete command. People should use the prebaked grubx64.efi binary that comes in the grub2-efi package, and is a signed binary so it can support UEFI Secure Boot.
If you run grub2-install, a new unsigned grub binary is created, replacing grubx64.efi. If you have Secure Boot enabled, you will not be able to boot, until you either reinstall the grub2-efi package (or you self-sign the grub2-install created binary and then go through the process of informing the firmware this is a valid binary by using mokutil - but I estimate maybe 1 in 50 people might do this).
Did you read my sentence "I recovered my Ubuntu grub menu ..." and that this mentions grub-install, not grub2-install ? The procedure that I describe is correct for Ubuntu - see e.g. https://askubuntu.com/questions/831216/reinstalling-grub2-efi-partition https://help.ubuntu.com/community/Grub2/Installing#Boot_repair_after_a_Windo...
The important point of my posting was to tell the OP the reason and mechanism which leads to a loss of the grub menu. The OP already described how s/he got the machine to boot again.
Hello Kay,
On Mon, 5 Feb 2018 16:27:19 +0100 Kay Diederichs kay.diederichs@uni-konstanz.de wrote:
On 02/01/2018 12:15 PM, wwp wrote:
Hello there,
Dell XPS-15-9560 laptop (SSD drive, UEFI, secure boot off).. Windows 10 pre-installed, CentOS7 installed in a separate partition and running for months w/o issue. Don't know what happened but at reboot yesterday (not even booted in Windows, just rebooted), grub has disappeared, booted in Windows by default, which apparently has taken over the UEFI boot.
The DELL XPS-13-9360 in its BIOS has an option (named "auto boot recovery" or similar - sorry the machine is somewhere else) that is by default enabled. I guess you have it enabled as well.
This option is triggered by two unsuccessful boot trials, and leads to the loss of the grub menu, and restoration of the (non-grub) "Windows boot manager" (or whatever it's called).
After being bit by it once, I disabled it.
At last I could reboot the system, and could verify that, you're right, there's a Bios option to restore factory settings in case of a (more or less) parametrable amount of boot failures. I disabled it as well, this is way too dangerous in case of booting from USB flashdrives (for instance) and can be enabled back if it's really needed. Thanks!
Regards,
-
Chris Murphy -
Kay Diederichs -
wwp