Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[wwp]

Hello Kay,


On Mon, 5 Feb 2018 16:27:19 +0100 Kay Diederichs 
 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,

-- 
wwp


pgp7fA12Kwgw2.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[Kay Diederichs]

On 02/05/2018 09:10 PM, Chris Murphy wrote:
> On Mon, Feb 5, 2018 at 8:27 AM, Kay Diederichs
>  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_Windows_Upgrade_on_Ubuntu_14.04_.28non-RAID.29

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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[Chris Murphy]

On Mon, Feb 5, 2018 at 8:27 AM, Kay Diederichs
 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).




-- 
Chris Murphy
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[Kay Diederichs]

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
> 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it) [SOLVED]

[wwp]

Hello Chris,


On Thu, 1 Feb 2018 13:25:14 -0700 Chris Murphy  wrote:

> On Thu, Feb 1, 2018 at 10:13 AM, wwp  wrote:
> > Hello Chris,
> >
> >
> > On Thu, 01 Feb 2018 17:00:03 + Chris Murphy  
> > 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
> > Boot* 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 DriveBBS(Floppy,Diskette Drive,0x0)..BO
> > Boot0003* M.2 PCIe SSD  BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO
> > Boot0004* USB Storage DeviceBBS(USB,KingstonDataTraveler 
> > 3.0PMAP,0x0)..BO
> > Boot0005* CD/DVD/CD-RW DriveBBS(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  -B' to delete them one by one; looks like you
> might be able to get away with just deleting 0001 and . 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
Boot* 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,

-- 
wwp


pgphuZ4c8WU74.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[Chris Murphy]

On Thu, Feb 1, 2018 at 10:13 AM, wwp  wrote:
> Hello Chris,
>
>
> On Thu, 01 Feb 2018 17:00:03 + Chris Murphy  
> 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
> Boot* 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 DriveBBS(Floppy,Diskette Drive,0x0)..BO
> Boot0003* M.2 PCIe SSD  BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO
> Boot0004* USB Storage DeviceBBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO
> Boot0005* CD/DVD/CD-RW DriveBBS(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  -B' to delete them one by one; looks like you
might be able to get away with just deleting 0001 and . 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.



-- 
Chris Murphy
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[wwp]

> I don't know what 0001 and 0002 refer to exactly (there's only one SSD
> drive in this laptop).

*and 0003*, sorry for the typo.


Regards,

-- 
wwp


pgpWM3bWQ2NHH.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[wwp]

Hello Chris,


On Thu, 01 Feb 2018 17:00:03 + Chris Murphy  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
Boot* 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 DriveBBS(Floppy,Diskette Drive,0x0)..BO
Boot0003* M.2 PCIe SSD  BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO
Boot0004* USB Storage DeviceBBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO
Boot0005* CD/DVD/CD-RW DriveBBS(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,

-- 
wwp


pgp_tNocGXvWx.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Re-enable grub boot in UEFI (Windows took over it)

[Chris Murphy]

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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos