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 ...
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.
*** This bug has been marked as a duplicate of bug 2010595 ***