Bug 255073 - boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer information
Summary: boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer informa...
Status: Closed DUPLICATE of bug 209821
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL: https://reviews.freebsd.org/D30828
Keywords:
Depends on: 256722
Blocks:
  Show dependency treegraph
 
Reported: 2021-04-15 02:54 UTC by Graham Perrin
Modified: 2022-01-09 05:33 UTC (History)
11 users (show)

See Also:


Attachments
Photograph of a boot drive (Verbatim STORE N GO PMAP) after the bug bites – no visible drive activity (24.78 KB, image/jpeg)
2021-04-15 02:54 UTC, Graham Perrin
no flags Details
A December 2020 photograph of the bug (814.40 KB, image/png)
2021-05-06 06:12 UTC, Graham Perrin
no flags Details
HP ProBook 450 G8 failure to boot from installer on USB (172.14 KB, image/jpeg)
2021-08-17 16:43 UTC, Graham Perrin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Perrin freebsd_committer 2021-04-15 02:54:24 UTC
Created attachment 224122 [details]
Photograph of a boot drive (Verbatim STORE N GO PMAP) after the bug bites – no visible drive activity

FreeBSD-13.0-RELEASE-amd64-bootonly.iso
FreeBSD-13.0-RELEASE-amd64-disc1.iso
FreeBSD-13.0-RELEASE-amd64-memstick.img

HP ProBook 440 G7
<https://support.hp.com/gb-en/document/c06474914>

Comparative test results: 
<https://gist.github.com/grahamperrin/5eca8231fa7e6a94a1f55991bcd7f3c4>

Photograph of the bug: 
<https://bz-attachments.freebsd.org/attachment.cgi?id=224114>
Comment 1 Graham Perrin freebsd_committer 2021-04-15 03:30:43 UTC
### Background

<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

  – omniosce-r151036.iso 
  – omniosce-r151036.usb-dd

* 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: 

> FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img 
> 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.
Comment 2 Graham Perrin freebsd_committer 2021-04-15 04:01:52 UTC
> … Graham Perrin … HP ProBook 440 G7

Adjacent bug 255072 for the same hardware not booting in legacy mode.

<https://h20195.www2.hp.com/v2/getpdf.aspx/c06424517.pdf> QuickSpecs
<https://support.hp.com/gb-en/document/c06474914>         specifications
<https://support.hp.com/gb-en/product/hp-probook-440-g7-notebook-pc/29090063>


(In reply to comment #1)

>> … Ludovit Koren … HP EliteBook 830 G7.

<https://www8.hp.com/h20195/v2/GetPDF.aspx/c06603675.pdf> QuickSpecs
<https://support.hp.com/gb-en/document/c06679914/>        specifications
<https://support.hp.com/gb-en/product/hp-elitebook-830-g7-notebook-pc/31971702>
Comment 3 Miguel Gomes 2021-04-22 12:51:52 UTC
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.
Comment 4 Graham Perrin freebsd_committer 2021-04-22 16:53:22 UTC
Thank you, 

(In reply to Miguel Gomes from comment #3)

> CSMbug 255072


----

> Elitebook 840 G6

<https://www8.hp.com/h20195/v2/getpdf.aspx/c06308183.pdf> QuickSpecs
<https://support.hp.com/gb-en/document/c06352019>     specifications
<https://support.hp.com/gb-en/product/hp-elitebook-840-g6-notebook-pc/26609796/>

* Intel UHD Graphics 620 – integrated

* AMD Radeon 550X (2 GB GDDR5 video memory) – discrete 
  (sold separately or as an optional feature)
Comment 5 Graham Perrin freebsd_committer 2021-04-22 17:00:16 UTC
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 
FreeBSD 12.2-RELEASE-p4.
Comment 6 Graham Perrin freebsd_committer 2021-05-06 06:12:23 UTC
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/>
Comment 7 Neel Chauhan freebsd_committer 2021-05-22 17:33:43 UTC
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).
Comment 8 David Sebek 2021-05-28 15:53:51 UTC
I was able to fix the boot hang issue on my system. See Bug 209821 for more details and a proposed patch.
Comment 9 Graham Perrin freebsd_committer 2021-06-19 17:44:44 UTC
More HP users having difficulty: 

FreeBSD on HP ProDesk G6 | The FreeBSD Forums
<https://forums.freebsd.org/threads/79252/>
Comment 10 Graham Perrin freebsd_committer 2021-06-20 03:58:27 UTC
(In reply to Graham Perrin from comment #0)

> HP ProBook 440 G7

Last week a colleague mentioned the G8. 

HP ProBook 440 G8

<https://h20195.www2.hp.com/v2/GetPDF.aspx/c06907851.pdf> QuickSpecs
<https://support.hp.com/gb-en/document/c06955072>         specifications

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.)
Comment 11 Graham Perrin freebsd_committer 2021-07-02 05:41:46 UTC
<https://forums.FreeBSD.org/threads/79252/post-518233>

> 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?
Comment 12 David Sebek 2021-07-04 20:26:07 UTC
(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.
Comment 13 Graham Perrin freebsd_committer 2021-07-06 06:17:31 UTC
David: thank you. 

Toomas: please, what next?
Comment 14 Graham Perrin freebsd_committer 2021-07-15 15:45:24 UTC
⚙ D31121 amd64 UEFI boot: stop copying staging area to 2M phys
<https://reviews.freebsd.org/D31121>
Comment 15 Graham Perrin freebsd_committer 2021-08-08 20:25:12 UTC
(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.
Comment 16 Graham Perrin freebsd_committer 2021-08-17 16:43:16 UTC
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 tried: 

FreeBSD-14.0-CURRENT-amd64-20210812-d20e9e02db3-248636-disc1.iso
FreeBSD-14.0-CURRENT-amd64-20210812-d20e9e02db3-248636-memstick.img

I did not try either of the following: 

copy_staging enable
copy_staging disable

– might do so tomorrow.
Comment 17 David Sebek 2021-08-17 18:19:45 UTC
(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.
Comment 18 Graham Perrin freebsd_committer 2021-08-18 00:05:18 UTC
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?
Comment 19 Graham Perrin freebsd_committer 2021-08-18 04:48:39 UTC
𠉥… probably ignore that question. 

(I forgot, the prompt for a GELI passphrase appears very early.)
Comment 20 Graham Perrin freebsd_committer 2021-08-19 02:59:18 UTC
(In reply to David Sebek from comment #17)

Unmodified boot

* failed as pictured in comment #16

copy_staging disable

* boot succeeded

copy_staging auto

* not yet tested.


Environment
===========

HP ProBook 450 G8

FreeBSD-14.0-CURRENT-amd64-20210812-d20e9e02db3-248636-disc1.iso 
written to a USB flash drive.
Comment 21 Graham Perrin freebsd_committer 2021-08-19 21:42:53 UTC
(In reply to Graham Perrin from comment #20)

copy_staging auto

* 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. …
Comment 22 Graham Perrin freebsd_committer 2021-10-05 21:02:50 UTC
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?
~~~^^^^^^^^^^^^^^^^^
Comment 23 Bjoern A. Zeeb freebsd_committer 2021-10-27 23:25:34 UTC
I still see this on arm64 with u-boot based boots with main from today.
Comment 24 parv 2021-11-29 12:21:36 UTC
FreeBSD image ...

  FreeBSD-13.0-RELEASE-amd64-memstick.img


... 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.
Comment 25 Graham Perrin freebsd_committer 2021-12-11 18:11:01 UTC
Noted with thanks: 

<https://www.freebsd.org/status/report-2021-07-2021-09/#_improved_amd64_uefi_boot>
Comment 26 Graham Perrin freebsd_committer 2021-12-28 03:38:25 UTC
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. 

Agreed? 

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.
Comment 27 Graham Perrin freebsd_committer 2022-01-09 03:55:56 UTC
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 ***