On Fri, Dec 02, 2022 at 02:25:53PM +0100, Laszlo Ersek wrote: > 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.
Right, of course - I forgot that this code only runs on the Windows guest path. > 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). Agreed, thanks. > > > >> + 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 <rjo...@redhat.com> > > > > 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. Great, I'll try to get a package into C9S before end of today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
