Firmware update (fwupdmgr) on HP Elitebook 845 G10 fails

… close to bricking device?!

First things first: Environment is HP Elitebook 845 G10, Endeavour OS with systemd-boot and dracut and latest update was on Friday, Mar, 22nd…

Procedere: I ran an update on firmware with the fwupdmgr. What works perfect on my 2 Thinkpads is some kind of weird on my new HP. The first fw update I did was right after I got it 3 months ago on an empty device and directly from BIOS - which is now not possible anymore due to “Windows Bitlocker” - LOL (I have Endeavour only with liks/lvm).

So I ran my triple sudo fwupdmgr refresh ; sudo fwupdmgr get-updates ; sudo fwupdmgr update and it found an downloaded the update and I needed to reboot.

Reboot stopped at HP Logo and I thought my device was bricked. I later found out that my NVRAM was nearly empty. I added my Endeavour “Linux Boot Manager” manually and I could boot again. Thanks god!!!

But I cannot get this fw update installed. No matter what I do I get stuck. And now even my FW update entry in NVRAM is gone.

What makes me wonder, too is, that the HP files are in a different subdir in efi/EFI. This directory looks like this (removed some unecessary lines):

[root@hp845 EFI]# ls -la --recursive
drwxr-x--- 2 root root 4096  5. Mär 16:56 BOOT
drwxr-x--- 3 root root 4096 23. Mär 13:50 endeavouros
drwxr-x--- 3 root root 4096 25. Mär 17:31 HP
drwxr-x--- 2 root root 4096  9. Dez 15:13 Linux
drwxr-x--- 2 root root 4096  5. Mär 16:56 systemd

-rw-r----- 1 root root 96768  3. Mär 18:04 BOOTX64.EFI

drwxr-x--- 2 root root  4096 25. Mär 16:50 fw
-rw-r----- 1 root root 66857 21. Mär 19:35 fwupdx64.efi


drwxr-x--- 2 root root 4096 25. Mär 17:31 DEVFW

-rw-r----- 1 root root   246398 25. Mär 17:31 ClickPad.bin
-rw-r----- 1 root root 42207151 19. Dez 17:48 Firmware.BIN
-rw-r----- 1 root root   279622 25. Mär 17:30 Realtek.bin


-rw-r----- 1 root root 96768  3. Mär 18:04 systemd-bootx64.efi

and the NVRAM (FW update is gone now but previously pointed to endeavouros/fwupdx64.efi):

[root@hp845 EFI]# efibootmgr 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0000* Linux Boot Manager	HD(1,GPT,d7c2654a-e0ac-4a14-b824-2012b64e8a33,0x1000,0x1f4000)/\EFI\systemd\systemd-bootx64.efi0400000049535048
Boot0001  USB: 	PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)4eac0881119f594d850ee21a522c59b21318000049535048

I wonder
a) why fwupdate has been killed
b) why it was on endeavouros/fwupdx86.efi before
c) why hp puts fw files in HP subdirectory and this has no entry in efibotmgr entries

I’m afraid i grill my laptop the next time. Can anybody give hints how this is supposed to work?

I found one guy with a simlar problem but with sligtly different setup, so I won’t follow steps there…
(Link: )

Just be careful as i ran fwupd on my desktop and it destroyed my grub boot loader. I’m not sure why because there wasn’t any updates to begin with. It’s not a tool i usually use but tried it once. :grinning:

1 Like

As I shared in another topic (related to the other user responding here), I’ve used fwupd for a long time without any issues and have yet to see any evidence that it destroys grub (though I’m happy to be proven wrong).

Some hardware manufacturers do have more issues than others and the one time I did have a complication was with an HP, although that was a desktop.

Regardless, the easiest fix for what you are describing is setting the reboot path to the HP download directory and your regular boot path should default to boot after the update is finished.

What you describe is fairly common. I recently had the same issue on a Dell SFF and changing the reboot directory was all that was needed. Once complete, you can verify it was successful with fwupd.

The best source for finding errors and fixes, that I’ve found is the fwupd GitHub. Fwupd is well supported and most of the major hardware manufacturers push updates to it, even when they’re not listed for download on their own websites. I’ve used it with both grub and systemd.

Edit: Corrected my statement to more accurately reflect what another user said.

No one say’s it kills grub. I said it wiped mine out and it did because it’s the only thing i used prior to it happening. Nothing has ever wiped it out before and that’s all i use is grub. I don’t normally update my firmware this way and I’ve also been doing it for years without issue. The issue maybe is not the same as what happened to mine and i just provided a caution as one never knows when these things can happen.

My apologies. I misquoted you.

I agree with you 110%.

Which is why the EOS forum is one of the best Arch forums out there. People are generally kind and helpful here. Unlike many others, in my personal experience.

1 Like

Thanks @misanthrope for your reply. Can you tell me where to set the “point to HP directory” - aka rebootpath? And as I have thre bin files instead of the fwupdx86.efi does it need an additional efimootmgr entry?

Or do you have a link with fürther information? (Meanwhile I’ll search by myself on fwupdmgr pages, but always open to good docs :wink: )


1 Like

I’m in a meeting for work at the moment and will be the rest of the day, so it will be a bit before I can get back to you.

In the mean time, have looked in your UEFI settings to see if there is a setting called ‘boot order lock’ or something similar to that? That could be causing the problem.

Also, I’m assuming you are running in UEFI mode and not legacy boot?

Have you looked at the Arch wiki?

1 Like

Yes, it’s UEFI and no boot order locking as far as I can see.

Will check fwupd @ arch - thx

by habit we use the flash on the highest level of the /boot/efi partition and not inside a directory, I refer to the situation of USB key case.

1 Like

From BIOS I selected an entry named “Install firmware compatible with your device” (Gerätekompatible Firmware installieren - German original title). The laptop then installed some Webcam firmware very quickly. Another try with fwupdmgr then shows no more updates available. I suppose this BIOS menu entry somehow found the stuff previously downloaded into EFI/HP/DEVFW

This is still to prove whenever the next fwupdmgr should fail…

Steps will then be:

  • select this BIOS menu entry and pray stuff gets installed
  • boot from live usb and use efibootmgr to recreate link to Linux Bootmanager like
    sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Linux Boot Manager" --loader "\\EFI\\systemd\\systemd-bootx64.efi"
  • optionally change bootorder with efibootmgr

$ man pray 
No manual entry for pray


1 Like

Maybe add a hook for that! :rofl:

I’m not that hooked up to the higher up :sweat_smile:

Maybe more :pray:

Maybe next time I’ll have to do a Bios update :wink:

1 Like

My apologies I didn’t get back to help with this. I’ve been very ill the past week. I’m glad it worked.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.