RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1515418 - RFE: Provide diagnostics for failed boot
Summary: RFE: Provide diagnostics for failed boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ovmf
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: FuXiangChun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-20 18:49 UTC by Dr. David Alan Gilbert
Modified: 2019-02-25 10:56 UTC (History)
9 users (show)

Fixed In Version: ovmf-20171011-4.git92d07e48907f.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 16:31:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
prototype on top of ovmf-20171011-1.git92d07e48907f.el7 (4.33 KB, patch)
2017-11-21 13:53 UTC, Laszlo Ersek 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0902 0 None None None 2018-04-10 16:31:20 UTC
TianoCore 513 0 None None None 2019-06-03 08:27:45 UTC

Description Dr. David Alan Gilbert 2017-11-20 18:49:59 UTC 
Description of problem:
If you try and boot a non-EFI disk image on OVMF, it quite often just sits at the logo and doesn't tell the user anything about what went wrong;  it looks like it just hung.  We need some diagnostics so it's obvious to the user they screwed up and need to fix their disk image.
This is especially important since we elected to remove both the EFI shell and the BIOS compatibility shim which 1) removes the easy way to debug and 2) makes it much more likely you'll hit it.  Oh and 3) EFI disc images are much more complex so screwing them up is much easier.

Version-Release number of selected component (if applicable):
OVMF-20170228-5

How reproducible:
100%

Steps to Reproduce:
1. Take a BIOS boot disk image
2. Boot it on an OVMF configured host 
3.

Actual results:
an OVMF boot logo screen

Expected results:
Trying to boot .....
FAILED because ....

Additional info:
Comment 3 Laszlo Ersek 2017-11-21 13:53:23 UTC 
Created attachment 1356689 [details]
prototype on top of ovmf-20171011-1.git92d07e48907f.el7

This is just a quick PoC. The actual upstream solution should use status code routing / handling / reporting. We already have some REPORT_STATUS_CODE() invocations in EfiBootManagerBoot() and BdsEntry(); some new ones should be added, and the current ones should emit more information (e.g. with EFI_STATUS_CODE_DATA_TYPE_DEBUG_GUID).
Comment 6 Laszlo Ersek 2017-11-23 00:01:04 UTC 
Posted upstream series:

[edk2] [PATCH 0/5] MdeModulePkg, OvmfPkg: more easily visible boot progress
                   reporting
http://mid.mail-archive.com/20171122235849.4177-1-lersek@redhat.com
https://lists.01.org/pipermail/edk2-devel/2017-November/017850.html
Comment 18 Laszlo Ersek 2017-11-29 14:04:56 UTC 
Steps for virt-QE, from Dave:

"""
a) Install a normal BIOS VM (e.g. Fedora or RHEL)
b) Use virt-manager to create a new VM, telling it to import the disk image from the VM in (a) but to customize the VM before install
c) During the customize, change the machine type/bios to q35+ovmf
d) Let it boot

Current versions stick at the Tianocore logo
This fix gives useful feedback and lets you get to the boot manager.
"""

Thanks.
Comment 21 Miroslav Rezanina 2017-12-06 14:12:17 UTC 
Fix included in ovmf-20171011-4.git92d07e48907f.el7
Comment 22 FuXiangChun 2017-12-12 02:07:37 UTC 
Reproduced this bug with OVMF-20171011-1.git92d07e48907f.el7.noarch & qemu-kvm-rhev-2.10.0-11.el7.x86_64.

Result:
1)stick at the Tianocore logo

2)OVMF log:
Error: Image at 0007CEA3000 start failed: Unsupported
Error: Image at 0007CDDF000 start failed: Unsupported
Error: Image at 0007CD6D000 start failed: Unsupported
Error: Image at 0007BE1A000 start failed: Unsupported
Error: Image at 0007BD34000 start failed: Aborted
[Bds] Unable to boot!

3) cann't get to the boot manager


Verified this bug with OVMF-20171011-4.git92d07e48907f.el7.noarch & qemu-kvm-rhev-2.10.0-11.el7.x86_64.

Result:
1)useful feedback as below:
BdsDxe: No bootable option or device was found.
BdsDxe: Press any key to enter the Boot Manager Menu.

2)type Enter, I can get to the boot manager.

3)part of ovmf log as below:

.......
SataControllerStart error return status = Already started
 BlockSize : 512 
 LastBlock : 77FFFFF 
 BlockSize : 512 
 LastBlock : 1FFFFF 
 BlockSize : 512 
 LastBlock : 75FF7FF 
SataControllerStart START
SataControllerStart error return status = Already started
 BlockSize : 512 
 LastBlock : 77FFFFF 
 BlockSize : 512 
 LastBlock : 1FFFFF 
 BlockSize : 512 
 LastBlock : 75FF7FF 
 BlockSize : 512 
 LastBlock : 77FFFFF 
 BlockSize : 512 
 LastBlock : 1FFFFF 
 BlockSize : 512 
 LastBlock : 75FF7FF 
 BlockSize : 512 
 LastBlock : 1FFFFF 
 BlockSize : 512 
 LastBlock : 75FF7FF 
[Bds] Expand \EFI\BOOT\BOOTX64.EFI -> <null string>
Comment 23 FuXiangChun 2017-12-12 02:08:29 UTC 
According to comment18 & comment22, set this bug as verified.
Comment 26 errata-xmlrpc 2018-04-10 16:31:01 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0902
Comment 28 Laszlo Ersek 2019-02-20 08:26:16 UTC 
Followup upstream patch series (possible candidate for a separate backport or rebase):

[edk2] [PATCH v2 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot progress reporting
https://lists.01.org/pipermail/edk2-devel/2019-February/036965.html
http://mid.mail-archive.com/20190220081644.8238-1-lersek@redhat.com
Comment 29 Laszlo Ersek 2019-02-21 10:44:16 UTC 
[edk2] [PATCH v3 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot progress reporting
https://lists.01.org/pipermail/edk2-devel/2019-February/037068.html
http://mid.mail-archive.com/20190221104112.14995-1-lersek@redhat.com
Comment 30 Laszlo Ersek 2019-02-25 10:56:57 UTC 
(In reply to Laszlo Ersek from comment #29)
> [edk2] [PATCH v3 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot
> progress reporting
> https://lists.01.org/pipermail/edk2-devel/2019-February/037068.html
> http://mid.mail-archive.com/20190221104112.14995-1-lersek@redhat.com

Upstream commit range 2df879827442..1797f32e0a19.
Note You need to log in before you can comment on or make changes to this bug.