HP Envy EFI Problem After BIOS Update

Home » CentOS » HP Envy EFI Problem After BIOS Update
CentOS 11 Comments

I had to boot my HP Envy into Win8 for the first time in ages this morning.
When I did that, it installed some updates including a BIOS update.

Once this was all done, once again the GRUB boot menu was gone and it booted straight into Win8. Using the advanced boot manager options in Win8 I
managed to get the EFI boot menu up and chose Ferdora 21.

It was only after Fedora failed to boot that I realised that this was wrong.
Some time ago I had replaced F21 with CentOS 7 and the three CentOS 7 options were the ones that should be available – plus the Windows 8 boot manager.

I have managed to boot into a CentOS 7 Live KDE image. In this ran efibootmgr which shows the same thing. I can fix the boot sequence, but that will not get me back the CentOS entries.

Can anyone suggest how I can do that?

Gary

[root@localhost ~]# efibootmgr BootCurrent: 0000
Timeout: 0 seconds BootOrder: 2002,0002,3002,0001,2001,2003
Boot0000* Internal CD/DVD ROM Drive (UEFI)
Boot0001* Fedora Boot0002* Windows Boot Manager Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
[root@localhost ~]#

11 thoughts on - HP Envy EFI Problem After BIOS Update

  • In some BIOS/firmwares you’ll have the option to ‘add’ an entry, and you can just point a new one to EFI/CentOS/shim.efi, save and be done with it.

    Otherwise you can do something like:

    efibootmgr -c -d /dev/sda -p 1 -L “CentOS” -l ‘\EFI\CentOS\shim.efi’

    there are a couple efi files inside /boot/efi/EFI/CentOS, but shim is the one to point to for secureboot to work properly.

  • Hi Jim,

    Thanks for this. I looked into what you said, and once happy I ran the command you gave. It appeared to work as it did not come up with any errors, and the output from efibootmgr showed
    1) CentOS had been added as an option and
    2) it was the first in the boot sequence.

    However, when I rebooted the laptop went straight into Win8, and after rebooting back into KDE Live, the option is no longer there.

    This is the output after rebooting.

    [root@localhost liveuser]# efibootmgr BootCurrent: 0000
    Timeout: 0 seconds BootOrder: 2002,0002,3002,0001,2001,2003
    Boot0000* Internal CD/DVD ROM Drive (UEFI)
    Boot0001* Fedora Boot0002* Windows Boot Manager Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
    [root@localhost liveuser]#

    This is me having a second attempt at your instructions. As you can see, it looks positive.

    [root@localhost liveuser]# efibootmgr -c -d /dev/sda -p
    1 -L “CentOS” -l ‘\EFI\CentOS\shim.efi’
    BootCurrent: 0000
    Timeout: 0 seconds BootOrder: 0003,2002,0002,3002,0001,2001,2003
    Boot0000* Internal CD/DVD ROM Drive (UEFI)
    Boot0001* Fedora Boot0002* Windows Boot Manager Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk Boot0003* CentOS
    [root@localhost liveuser]#

    I have had a look at /boot and can see in there the CentOS directory, but not a Fedora one. Is this not the boot fs from the hss?

    [root@localhost liveuser]# ll /boot/efi/EFI/
    total 8
    drwxr-xr-x. 2 root root 4096 Sep 6 11:32 BOOT
    drwxr-xr-x. 3 root root 4096 Sep 6 11:32 CentOS
    [root@localhost liveuser]# ll /boot/efi/EFI/CentOS/
    total 5772
    -rw-r–r–. 1 root root 128 Dec 7 2015 BOOT.CSV
    drwxr-xr-x. 2 root root 4096 Sep 6 11:32 fonts
    -rwxr-xr-x. 1 root root 1009536 Jan 5 2016 gcdx64.efi
    -rwxr-xr-x. 1 root root 1009536 Jan 5 2016 grubx64.efi
    -rw-r–r–. 1 root root 1283952 Dec 7 2015 MokManager.efi
    -rw-r–r–. 1 root root 1291512 Dec 7 2015 shim-CentOS.efi
    -rw-r–r–. 1 root root 1296176 Dec 7 2015 shim.efi
    [root@localhost liveuser]#

  • I don’t know if this additional information helps. Looking at he efibootmgr output, is the CentOS entry pointing to the right place?

    Also, any idea why the update isn’t being make permenant?

    [root@localhost boot]# parted GNU Parted 3.1
    Using /dev/sda Welcome to GNU Parted! Type ‘help’ to view a list of commands.
    (parted) print
    Model: ATA ST1000LM014-1EJ1 (scsi)
    Disk /dev/sda: 1000GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: gpt Disk Flags:

    Number Start End Size File system Name Flags
    1 1049kB 683MB 682MB ntfs Basic data partition hidden, diag
    2 683MB 892MB 210MB fat16 EFI System Partition boot
    4 1089MB 212GB 211GB ntfs Basic data partition
    3 212GB 213GB 524MB ext4
    6 213GB 214GB 524MB xfs
    7 214GB 978GB 765GB lvm
    5 978GB 1000GB 21.8GB ntfs Basic data partition hidden

    (parted) quit
    [root@localhost boot]# efibootmgr -v BootCurrent: 0000
    Timeout: 0 seconds BootOrder: 0003,2002,0002,3002,0001,2001,2003
    Boot0000* Internal CD/DVD ROM Drive (UEFI)
    ACPI(a0341d0,0)PCI(1f,2)SATA(2,0,0)CD-ROM(1,2b,272c)RC
    Boot0001* Fedora
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)File(\EFI\fedora\shim.efi)RC
    Boot0002* Windows Boot Manager
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)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.}……………….. Boot0003* CentOS
    HD(1,800,145000,277e20d2-ee46-412b-babb-9b2249324ca4)File(\EFI\CentOS\shim.efi)
    Boot2001* USB Drive (UEFI) RC
    Boot2002* Internal CD/DVD ROM Drive (UEFI) RC
    Boot3000* Internal Hard Disk or Solid State Disk RC
    Boot3002* Internal Hard Disk or Solid State Disk RC
    [root@localhost boot]#

  • All of the following is still under the CentOS 7 KDE Live CD:

    If I mount /dev/sda2 on /media and have a look, this is the valid EFI
    filesystem, including the Fedora and CentOS entries.

    If I try to mount /dev/sda6 on /media it looks to be a valid /boot filesystem.

    If I mount /dev/sda6 as /boot and mount /dev/sda2 as /boot/efi before running Jim’s efibootmgr command will I fix the problem or will I stuff it beyond all recognition?

    [root@localhost /]# mount /dev/sda2 /media/
    [root@localhost /]# cd /media/
    [root@localhost media]# ll total 12
    drwxr-xr-x. 7 root root 4096 Sep 14 12:20 EFI
    drwxr-xr-x. 2 root root 4096 Aug 15 10:24 System Volume Information drwxr-xr-x. 2 root root 4096 Jul 14 2015 Temp
    [root@localhost media]# cd EFI/
    [root@localhost EFI]# ll total 20
    drwxr-xr-x. 2 root root 4096 Dec 10 2015 BOOT
    drwxr-xr-x. 3 root root 4096 Sep 12 12:04 CentOS
    drwxr-xr-x. 4 root root 4096 Nov 23 2015 fedora drwxr-xr-x. 5 root root 4096 Sep 14 12:20 HP
    drwxr-xr-x. 3 root root 4096 Jul 3 2015 Microsoft
    [root@localhost EFI]# cd
    [root@localhost ~]# umount /media/
    [root@localhost ~]# mount /dev/sda6 /media/
    [root@localhost ~]# cd /media/
    [root@localhost media]# ll total 243120
    -rw-r–r–. 1 root root 126431 Aug 3 12:21
    config-3.10.0-327.28.2.el7.x86_64
    -rw-r–r–. 1 root root 126431 Aug 18 20:15
    config-3.10.0-327.28.3.el7.x86_64
    -rw-r–r–. 1 root root 126426 Nov 19 2015 config-3.10.0-327.el7.x86_64
    drwxr-xr-x. 2 root root 6 Aug 15 07:34 efi drwxr-xr-x. 2 root root 26 Dec 10 2015 grub drwx——. 3 root root 33 Aug 15 11:27 grub2
    -rw-rw-r–. 1 root root 57630181 Aug 15 07:46
    initramfs-0-rescue-94f9d612ea4e4d2497d367334416d88b.img
    -rw-r–r–. 1 root root 30853341 Aug 15 16:48
    initramfs-3.10.0-327.28.2.el7.x86_64.img
    -rw-r–r–. 1 root root 19329078 Aug 15 11:55
    initramfs-3.10.0-327.28.2.el7.x86_64kdump.img
    -rw-r–r–. 1 root root 30855404 Sep 12 11:04
    initramfs-3.10.0-327.28.3.el7.x86_64.img
    -rw-r–r–. 1 root root 19329625 Sep 12 11:06
    initramfs-3.10.0-327.28.3.el7.x86_64kdump.img
    -rw-r–r–. 1 root root 30852186 Aug 15 16:48
    initramfs-3.10.0-327.el7.x86_64.img
    -rw-r–r–. 1 root root 19217036 Aug 15 11:12
    initramfs-3.10.0-327.el7.x86_64kdump.img
    -rw-r–r–. 1 root root 10193251 Dec 10 2015 initrd-plymouth.img
    -rw-r–r–. 1 root root 252632 Aug 3 12:23
    symvers-3.10.0-327.28.2.el7.x86_64.gz
    -rw-r–r–. 1 root root 252632 Aug 18 20:17
    symvers-3.10.0-327.28.3.el7.x86_64.gz
    -rw-r–r–. 1 root root 252612 Nov 19 2015 symvers-3.10.0-327.el7.x86_64.gz
    -rw——-. 1 root root 2964683 Aug 3 12:21
    System.map-3.10.0-327.28.2.el7.x86_64
    -rw——-. 1 root root 2964731 Aug 18 20:15
    System.map-3.10.0-327.28.3.el7.x86_64
    -rw——-. 1 root root 2963044 Nov 19 2015 System.map-3.10.0-327.el7.x86_64
    -rwxr-xr-x. 1 root root 5156528 Aug 15 07:46
    vmlinuz-0-rescue-94f9d612ea4e4d2497d367334416d88b
    -rwxr-xr-x. 1 root root 5159792 Aug 3 12:21
    vmlinuz-3.10.0-327.28.2.el7.x86_64
    -rwxr-xr-x. 1 root root 5159792 Aug 18 20:15
    vmlinuz-3.10.0-327.28.3.el7.x86_64
    -rwxr-xr-x. 1 root root 5156528 Nov 19 2015 vmlinuz-3.10.0-327.el7.x86_64
    [root@localhost media]#

  • Probably because the specified file wasn’t found by the firmware on partition 1, so it removed what it thinks is a bogus entry. Just a guess.

    The proper command in this case is

    efibootmgr -c -d /dev/sda -p 2 -L CentOS -l \\EFI\\CentOS\\shim.efi

    efibootmgr -v is more rewarding

    Looks fine. But notice the boot order:
    BootOrder: 0003,2002,0002,3002,0001,2001,2003

    That puts Fedora in 5th place. You need to use efibootmgr -n 0001 to do a one time boot of Fedora at next boot; or you need to use efibootmgr -o and explicitly change the entire boot order, separated by commas.

    I have no idea what RC at the end of these lines means though.

  • Multiboot is basically a PITA, the Ux sucks. Almost invariably you’re better off figuring out how to navigate the firmware’s boot manager to choose Windows vs Fedora vs CentOS; where you can use efibootmgr -o to get the bootorder such that the first entry at least is the one you usually want to boot by default. And then use the firmware’s boot manager to pick something else as an exception. Although I sometimes find efibootmgr -n as a one time boot is neat.

    If you want to standardize on a single GRUB boot menu that has all options available, this is basically total shit right now, you have to do it manually because between grub2-mkconfig and os-prober, they aren’t smart enough to create the proper boot entries. It *should* be true that it’ll create the proper boot entry for Windows, but only Fedora 24’s GRUB supports Secure Boot chainloading the Windows bootloader, the CentOS one can boot the kernel with Secure Boot enabled, but can’t chainload another bootloader with Secure Boot enabled. So the first step is you have to standardize on the Fedora 24
    version of GRUB if you want to use Secure Boot and I can only advise that you do because generally I think it’s bad advice to disable it.

    Next, how to boot CentOS from the Fedora 24 GRUB menu? grub2-mkconfig and os-prober conspire to create wholly new CentOS boot entries rather than using the unique CentOS boot entries; and further if you do a CentOS kernel update, that’ll only update the CentOS grub.cfg not the Fedora one. This is why this is such shit. What I do is disable os-prober entirely by adding GRUB_DISABLE_OS_PROBER=”true” to
    /etc/default/grub and then take your pick between
    /etc/grub.d/40_custom and /etc/grub.d/41_custom: the first one you just add the entry directly in that file, and the 2nd one you create a drop in cfg of your own called custom.cfg. It’s probably a little more reliable to use 41_custom because any of these files can be replaced with a grub update.

    So your menu entry should be something like this:

    menuentry ‘CentOS menu’ {
    configfile /EFI/CentOS/grub.cfg
    }

    Now grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

    And what you ought to have if I didn’t mess that up, is a CentOS item in the Fedora menu, and when you click that, it’ll read and use the CentOS grub.cfg instead. Now you get all the custom CentOS boot params, and whenever CentOS gets a kernel update and updates its grub.cfg, you’ll see those changes without having to do anything.

    Chris Murphy

  • I have managed to boot into the installed CentOS system, without using the KDE
    live CD.

    By pressing F9 when turning on the laptop, I got the choose boot menu. When the menu appeared, it had the old Fedora install, the current CentOS install as well as the Windows install.

    When I chose the CentOS install it showed the GRUB menu and booted into CentOS
    without error. This confirms that the CentOS entry in the EFI data is still valid.

    Once booted I then tried going through the process of running efibootmgr again. Once again, it looked to work perfectly, but for some reason the changes are not permenant, and if left alone, the laptop boots into Win8.

    I’m out of ideas now.

    Gary

    [root@gary ~]# efibootmgr -v BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 0002,3002,0000,0003,2001,2002,2003
    Boot0000* Fedora
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)File(\EFI\fedora\shim.efi)RC
    Boot0002* Windows Boot Manager
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)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.}……………….. Boot0003* CentOS Linux
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)File(\EFI\CentOS\shim.efi)
    Boot2001* USB Drive (UEFI) RC
    Boot2002* Internal CD/DVD ROM Drive (UEFI) RC
    Boot3000* Internal Hard Disk or Solid State Disk RC
    Boot3002* Internal Hard Disk or Solid State Disk RC
    [root@gary ~]# efibootmgr -b 0000 -B
    BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 0002,3002,0003,2001,2002,2003
    Boot0002* Windows Boot Manager Boot0003* CentOS Linux Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
    [root@gary ~]# echo $?
    0
    [root@gary ~]# efibootmgr -o 2002,2001,0003,0002
    BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 2002,2001,0003,0002
    Boot0002* Windows Boot Manager Boot0003* CentOS Linux Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
    [root@gary ~]#[root@gary ~]# efibootmgr -v BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 0002,3002,0000,0003,2001,2002,2003
    Boot0000* Fedora
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)File(\EFI\fedora\shim.efi)RC
    Boot0002* Windows Boot Manager
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)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.}……………….. Boot0003* CentOS Linux
    HD(2,145800,64000,14c4ac1d-abd8-4121-84ee-c05a825920de)File(\EFI\CentOS\shim.efi)
    Boot2001* USB Drive (UEFI) RC
    Boot2002* Internal CD/DVD ROM Drive (UEFI) RC
    Boot3000* Internal Hard Disk or Solid State Disk RC
    Boot3002* Internal Hard Disk or Solid State Disk RC
    [root@gary ~]# efibootmgr -b 0000 -B
    BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 0002,3002,0003,2001,2002,2003
    Boot0002* Windows Boot Manager Boot0003* CentOS Linux Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
    [root@gary ~]# echo $?
    0
    [root@gary ~]# efibootmgr -o 2002,2001,0003,0002
    BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 2002,2001,0003,0002
    Boot0002* Windows Boot Manager Boot0003* CentOS Linux Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk
    [root@gary ~]#

  • Chris,

    They were included in my last email, along with the output

    # get the current state efibootmgr -v

    # set the boot order DVD, USB, CentOS, Windows

    efibootmgr -o 2002,2001,0003,0002

    # I have also tried 0003,0002,2002

    # remove the expired Fedora option

    efibootmgr -b 0000 -B

    The output after the last command shows the EFI state exactly as I want it, but unfortunately, it isn’t persistant

    BootCurrent: 0003
    Timeout: 0 seconds BootOrder: 0002,3002,0003,2001,2002,2003
    Boot0002* Windows Boot Manager Boot0003* CentOS Linux Boot2001* USB Drive (UEFI)
    Boot2002* Internal CD/DVD ROM Drive (UEFI)
    Boot3000* Internal Hard Disk or Solid State Disk Boot3002* Internal Hard Disk or Solid State Disk

  • Well that’s me stuffed again,

    I did get to the point where I could press F9 and then select the CentOS EFI
    entry.

    The problem only occurred after Windows installed a BIOS update, taking me from F.65 to F.67. One of the first things I did to try to fix the problem was to roll back F.65.

    This morning I thought I would re-apply the update and see if it made any difference. Unfortunately it did. Wnce I was on F.67, when I pressed F9 the menu was missing the CentOS option, only showing “

    OS Boot Manager Fedora (ST1000LM014-1EJ164-SSHD)
    Boot From EFI File

    While collecting the above details, I tried the last option which then gave me the options:

    NO VOLUME LABEL


    shim.efi

    At which point CentOS then booted.

    Anyone got any ideas what I need to do next.

    Also, I tried rolling back to F.65 again to see if that would return the CentOS option to the F9 menu but it didn’t

  • Try efibootmgr -v -O -T ## capital O, to delete the entire boot order and timeout efibootmgr -v -o 3,2 -t 3

    I think making the DVD or USB the default boot options is a bad idea, I wouldn’t do that. Use the boot manager on demand if you need to boot DVD or USB. The things that should be listed first are the things you want booted by default and then the next fallback.

    The other thing to do is check HP’s web site directly for an even newer version of the firmware. It may be the one you have fixes a particular bug Microsoft is bothered by but may have an NVRAM garbage collection bug that they don’t care about or don’t know about (yet).