Re: [Libguestfs] [v2v PATCH 2/2] convert_windows: fix up the UEFI fallback boot loader if broken

On 12/02/22 13:58, Richard W.M. Jones wrote: > On Fri, Dec 02, 2022 at 01:44:09PM +0100, Laszlo Ersek wrote: >> + info (f_"Fixing UEFI bootloader."); >> + g#rm_rf bootdir; >> + g#mkdir_p bootdir; > > Is it safe to completely delete this directory or would it be better > to only delete the errant BOOTX64.efi file? I'm just wondering if > anything else important might be stored here. Yes I think we *should* delete the \EFI\BOOT directory in this case. We've determined that a Windows OS is installed on the disk, and I've not seen any Windows version yet where \EFI\BOOT contained any other file than BOOTX64.efi (or BOOTX32.efi), with the file being a copy of bootmgfw.efi at that.

In the particular problem scenario <https://bugzilla.redhat.com/show_bug.cgi?id=2149629#c6>;, replacing only the BOOTX64.efi file (= shim) with a copy of bootmgfw.efi would produce a \EFI\BOOT directory containing two files: - BOOTX64.efi (= bootmgfw.efi) - fbx64.efi (from the shim installation) While that might not necessarily cause runtime issues, it's certainly confusing for any human reader (does not look like pristine ESP contents with Windows installed).

> >> + g#cp_a bootmgfw fallback >> + ) >> in >> >> match inspect.i_firmware with >> | I_BIOS -> () >> | I_UEFI esp_list -> >> let esp_temp_path = g#mkdtemp "/Windows/Temp/ESP_XXXXXX" in >> + let uefi_arch = get_uefi_arch_suffix inspect.i_arch in >> >> List.iter ( >> fun dev_path -> >> g#mount dev_path esp_temp_path; >> fix_win_uefi_bcd esp_temp_path; >> + (match uefi_arch with >> + | Some uefi_arch -> fix_win_uefi_fallback esp_temp_path uefi_arch >> + | None -> () >> + ); >> g#umount esp_temp_path; >> ) esp_list; > > Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com&gt; > > If you can push this (optionally changed/fixed as you see fit) in the > next hour then I can put it into C9S, since I'm doing a build today > anyway. Thanks, I'll push the series in a few minutes.