Bug 2014257

Summary:	shim doesn't load anything but grub
Product:	[Fedora] Fedora	Reporter:	Roman Kagan <rvkagan>
Component:	shim	Assignee:	Peter Jones <pjones>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	34	CC:	fmartine, mjg59, pbrobinson, pjones, rharwood
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-29 21:43:13 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 Roman Kagan 2021-10-14 18:08:39 UTC

Description of problem:

On my Lenovo Thinkpad X1 Carbon Gen6 firmware capsue updates don't get installed because the system never boots into the updater application.

It used to work with some earlier versions but doesn't now.  Essentially the only way to install the updates is to manually set up a boot entry, temporarily disable SecureBoot, boot into the updater, and then restore SecureBoot.

Verbose logs, when set up with "mokutil --set-verbosity true", suggest that shim does find fwupdx64.efi but then loads grubx64.efi.

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

shim-x64-15.4-4.x86_64

How reproducible:

100%%

Steps to Reproduce:
1. install an update with fwupdmgr
2. verify there's a boot entry for it
3. reboot

Actual results:

system boots again into grub then linux

Expected results:

fwupdx64.efi is executed and sets up a firmware update

Additional info:

The logs contain (approximate wording as remembered while watching the logs scroll)

...
is_our_path:XXX:dbpath: \EFI\fedora\shimx64.efi
is_our_path:XXX:path:   \fwupdx64.efi
load_imge:XXX:attempting to load \EFI\fedora\shimx64.efi
...

Comment 1 Roman Kagan 2021-10-14 18:12:42 UTC

AFAICT from the source code, shim.c:set_second_state:

EFI_STATUS set_second_stage (EFI_HANDLE image_handle)
{
	...
	UINTN loader_len = 0;
	...
	UINTN strings = count_ucs2_strings(li->LoadOptions,
					   li->LoadOptionsSize);
	...
	if (strings == 0) {
		efi_status = get_load_option_optional_data(li->LoadOptions,
							   li->LoadOptionsSize,
							   (UINT8 **)&start,
							   &loader_len);
		...
	} else if (strings >= 2) {
		...
	} else if (strings == 1 && is_our_path(li, start)) {
		...
	}
	...
	if (loader_len > 0) {
		loader_str = ... make a copy of the loader path ...;
		...
		second_stage = loader_str;
		...
	}
	...
}

that is, in the case where the path of the second stage is found in li->LoadOptions as a string rather than a full-fledged EFI_LOAD_OPTION, loader_len remains 0 and second_stage is not updated with the string just found, so shim loads the default second stage (grubx64.efi) regardless of the options.

FWIW the code on branch shim-15.5 seems to have this problem resolved.

Comment 2 Peter Robinson 2021-11-29 21:43:13 UTC


*** This bug has been marked as a duplicate of bug 2010595 ***