Created attachment 224122 [details]
Photograph of a boot drive (Verbatim STORE N GO PMAP) after the bug bites – no visible drive activity
HP ProBook 440 G7
Comparative test results:
Photograph of the bug:
<https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/> (2020-12-04) observed that a previously available HP ProBook 440 G7:
* did boot from installers for OmniOS community edition
* did _not_ boot from installers for FreeBSD 12.2 or 13.0-CURRENT
* did _not_ boot from the installer for GhostBSD.
From the postscripts there:
> FreeBSD bug 244906 – kernel booted by loader.efi on
> VMware Fusion crashes in EFI firmware
> * discussion in IRC suggests that the
> root cause may be the same
> * Toomas Soome (tsoome) thinks that mine is the
> second hardware instance of the bug.
Bug 244906 became a duplicate of later bug 251866:
> Because the loader.efi modified the size of EFI_STAGING_SIZE,
> vmware could not start the system above FreeBSD 12.2
<https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077970.html> (2020-12-25) Ludovit Koren wrote:
> still not working on HP EliteBook 830 G7.
Bug 251866 comment 31 (2021-04-14):
> There's been a lot of chance since 12.x. this may be unrelated to
> this size change and should have a new bug assigned to it, I think,
> so we don't conflate the two issues if they are indeed separate.
> … Graham Perrin … HP ProBook 440 G7
Adjacent bug 255072 for the same hardware not booting in legacy mode.
(In reply to comment #1)
>> … Ludovit Koren … HP EliteBook 830 G7.
I can also confirm this issue on an Elitebook 840 G6. Can also confirm it happens both in CSM and UEFI only modes. Both with Secure Boot disabled.
Update to date UEFI firmware as of April 2021.
(In reply to Miguel Gomes from comment #3)
▶ bug 255072
> Elitebook 840 G6
* Intel UHD Graphics 620 – integrated
* AMD Radeon 550X (2 GB GDDR5 video memory) – discrete
(sold separately or as an optional feature)
Does it help to compare with boot failures for NomadBSD?
<https://forum.nomadbsd.org/t/-/689?u=grahamperrin> begins with my case
(HP ProBook 440 G7).
Re: <https://nomadbsd.org/index.html#1.4> NomadBSD 1.4 is based on
Created attachment 224721 [details]
A December 2020 photograph of the bug
… for convenience. I should have attached this at the outset.
Copied from <https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/>
I have a TigerLake HP Spectre x360 13t-aw200 and it doesn't have this error on 13.x/14-CURRENT that the ProBook/EliteBook. The same with the WhiskeyLake Spectre x360 13-ap0053dx. My TigerLake Spectre has no CSM, and the WhiskeyLake Spectre has the CSM disabled.
It seems consumer HP fortunately do not have the same bug as the "enterprise" ProBook/EliteBook models. Well, thank god I cancelled an EliteBook order for my Spectre. Sure, I don't have drm-kmod support but at least I can boot my laptop.
I have not used an EliteBook newer than KabyLake, and work gives me a ThinkPad that technically "dual boots" FreeBSD but always runs Windows 10 (disclaimer: I work at Microsoft but not on Windows or UEFI firmware).
I was able to fix the boot hang issue on my system. See Bug 209821 for more details and a proposed patch.
More HP users having difficulty:
FreeBSD on HP ProDesk G6 | The FreeBSD Forums
(In reply to Graham Perrin from comment #0)
> HP ProBook 440 G7
Last week a colleague mentioned the G8.
HP ProBook 440 G8
Announced in September 2020, I see: <https://www8.hp.com/content/dam/sites/garage-press/press/press-kits/2020/2020-hp-reinvent/hp_probook_440_g8.pdf>
Whether the G8 is becoming standard issue at my place of work, I don't yet know. (I can't expect to receive anything other than the standard. Partly due to the incompatibility with FreeBSD, I have long refrained from requesting a replacement for a (compatible) circa 2013 EliteBook 8570p.)
> Can you try replacing the /EFI/BOOT/bootx64.efi file on the
> EFI partition of your boot flash drive with the bootx64.efi
> file I am attaching to see if it boots? It has the patch from
> Bug 209821 applied to it.
David: thank you.
Using a computer that's not bugged, I installed FreeBSD 13.0-RELEASE to a USB flash drive then put your patched bootx64.efi in place.
I attempted to boot an HP ProBook 440 G8 from the drive. No change to the symptoms, as far as I can tell; no progress beyond presentation of EFI framebuffer information.
Is it enough to have the patched file in the EFI partition? Or must the file (also) be copied elsewhere, maybe with a different name?
(In reply to Graham Perrin from comment #11)
I don't have a HP ProBook, but my computers load the EFI/boot/bootx64.efi file, no other files need to be changed.
If there are no warning messages on the screen when it freezes, then you are likely experiencing a problem that is different from what my patch tries to address. Your problem could be located somewhere in the late stages of the boot loader or in the very early stages of the kernel.
David: thank you.
Toomas: please, what next?
⚙ D31121 amd64 UEFI boot: stop copying staging area to 2M phys
(In reply to Graham Perrin from comment #14)
<https://cgit.freebsd.org/src/commit/?id=f75caed644a5c8c342a1ea5e7a6d5251f82ed0b1> noted with thanks.
<https://www.freebsd.org/where/#_freebsd_14_0_current> I'll test after the next snapshot is produced.
Created attachment 227286 [details]
HP ProBook 450 G8 failure to boot from installer on USB
I can boot a very recently built installation of 14.0-CURRENT with (if I recall correctly) a copy of a loader that was made whilst testing D31121, however …
… the same computer can _not_ boot, from a USB flash drive, the most recent _installer_.
I did not try either of the following:
– might do so tomorrow.
(In reply to Graham Perrin from comment #16)
I successfully booted the latest 14.0-CURRENT image on my Sandy Bridge Samsung laptop. I had to change the value of copy_staging, which used to default to “auto” before the patch was committed, but it now defaults to “enable” (old behavior).
Try copy_staging disable or copy_staging auto.
To persist the change, I added exec=“copy_staging auto” to /boot/loader.conf.
Thanks, I'll try.
(In reply to David Sebek from comment #17)
> … To persist the change, I added exec=“copy_staging auto” to /boot/loader.conf.
Where there's GELI encryption: what might be done for the ESP?
𠉥… probably ignore that question.
(I forgot, the prompt for a GELI passphrase appears very early.)
(In reply to David Sebek from comment #17)
* failed as pictured in comment #16
* boot succeeded
* not yet tested.
HP ProBook 450 G8
written to a USB flash drive.
(In reply to Graham Perrin from comment #20)
* boot succeeded.
Bug 256722 comment 5 advises:
> … improvements added by the patch D31121 are disabled by default,
> I think that patch D30828 is still relevant. …
From bug 209821 comment 54:
> This issue (209821) should be resolved by kib's commit. Anyone who was
> able to reproduce this, can you please test with a -CURRENT snapshot
> (20210930 or later) and report whether it works for you?
I still see this on arm64 with u-boot based boots with main from today.
FreeBSD image ...
... had failed to boot on Supermicro X10SRL-F motherboard with c 2015 AMI BIOS v2.0 both in "UEFI" & "DUAL" modes. Boot sequence was stuck at "EFI framerbuffer information" message.
Booted & installed in the third boot mode of "BIOS" (or could have been "LEGACY") mode.
Earlier, some 12-RELEASE had been installed either in "DUAL" or "UEFI" mode. From recent boot logs, it was booting in EFI mode IIRC but can't be certain without logs lost now.
Noted with thanks:
emaste, I currently lean towards closing this bug 255073
as a duplicate of bug 209821
> UEFI - installation media hangs when booting
> on ASUS P6P67 DELUXE
-- and ignore the Asus aspect of the summary line there.
Or should we leave 255073 open? Maybe for discoverability (its summary line and HTML title), after which the person discovering can subscribe to a linked bug.
Until now, my main reason for keeping 255073 open, not rushing to close, was its unusual history. Re: comment 1, some HP hardware-oriented reporting was previously directed into a (non-hardware) VMWare-related bug.
Closure at bug 209821 comment 74, it seems sensible to close this bug 255073 as a duplicate.
*** This bug has been marked as a duplicate of bug 209821 ***