Bug 1221780

Summary:	how to identify firmware types, UEFI vs BIOS
Product:	[Retired] Fedora Documentation	Reporter:	Chris Murphy <bugzilla>
Component:	multiboot-guide	Assignee:	Pete Travis <me>
Status:	CLOSED EOL	QA Contact:	Fedora Docs QA <docs-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	devel	CC:	bugzilla, me, swadeley
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-07 15:29:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Murphy 2015-05-14 19:52:21 UTC

I'm not finding advice in documentation to identify firmware type. Should we, and if so where should it go?

Identifying firmware type comes in handy e.g. reinstalling grub, see bug 1220066.

The problem is, users overwhelmingly equate UEFI and BIOS, often referring to it as UEFI BIOS, mainly because OEM's still call firmware updates "BIOS updates".

Two possible ways to reliably identify UEFI vs BIOS firmware.

On an EFI system:
# ls /sys/firmware/efi
config_table  efivars  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

On a BIOS system:
# ls /sys/firmware/efi
ls: cannot access /sys/firmware/efi: No such file or directory

----

On an EFI system:
# efibootmgr
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* Fedora
Boot0080* Mac OS X
Boot0082* 
BootD1A6* AST
BootFFFF* 

On a BIOS system:
# efibootmgr
efibootmgr: EFI variables are not supported on this system.


Unknowns:

The first method always works since ls is for sure installed no matter what. I need to test if efibootmgr is always installed, e.g. netinstall (?), it definitely is always installed from lives. But if it's not installed, then it's not a UEFI system.

How does coreboot firmware manifest? I think it's mainly a "better BIOS" and should behave as such.

ARM firmware?

Comment 1 Pete Travis 2015-05-14 20:57:04 UTC

Hey Chris,

I've written https://fedorapeople.org/groups/docs/multiboot-guide/#BOOT-BIOS_or_UEFI . Trying to keep it simple there, and it's mostly pre-installation context (keeping in mind that it is possible to boot a UEFI system in legacy mode.)

We're hoping to publish this with F22 GA. Does this fit what you're looking for?

Comment 2 Chris Murphy 2015-05-14 22:22:24 UTC

Yes! Obviously I didn't look very thoroughly. It's almost perfect, here are some comments:

- "Your computer originally shipped with Windows Vista or XP." Could be:
"Your computer originally shipped with Windows XP, Windows Vista, or Windows 7."

- Under "Identifying a UEFI system"
"Any Apple Mac with an Intel CPU is considered to have UEFI firmware."


There's a class of hardware floating around now that doesn't initialize USB in the pre-boot environment, so there's no way to get to a firmware setup or boot menu. That in and of itself suggests it's UEFI. But I guess we can see if there's much user confusion on this point before extending the section to account for it.

Comment 3 Stephen Wadeley 2016-05-19 19:39:27 UTC

Hello

Do I need to do anything in the Sysadmin Guide? or can I close?


I see Multiboot Guide is now here:

https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/BOOT-BIOS_or_UEFI.html

Thank you

Comment 4 Chris Murphy 2016-05-19 20:00:31 UTC

"Your computer shipped with Windows 8" could be

"Your computer shipped with Windows 8 or newer"

Otherwise I think it can be closed.

Comment 5 Stephen Wadeley 2016-05-19 20:06:40 UTC

Thank you Chris

Hello Pete

Please ACK etc., then close.

Thank you

Comment 6 Petr Bokoc 2019-11-07 15:29:58 UTC

I'm closing this bug as part of a Bugzilla cleanup effort. The most likely reason is that the bug has been opened either against a component we no longer publish, or against Release Notes for an EOL release.

Comment 7 Red Hat Bugzilla 2023-09-14 02:59:14 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days