Il 10/12/2016 20:11, Andrei Borzenkov ha scritto: > > Oops; that is EFI_NOT_FOUND which according to specs is returned when > "Both SourceBuffer and DevicePath are NULL". But DevicePath (which is > passed as file_path here) cannot be NULL, we check for that earlier, and > you also get file path printed, right? OTOH it may be returned by > underlying protocol (like LOAD_FILE_PROTOCOL) which does mean "file not > found". > > Could you please > > a) compare device path printed by chainloader with and without secure > boot active? May be make a photo in each case and make them available - > I'd like to see exact output (without yadda etc). >
OK, I did everything. So, a few important info: - efibootmgr verbose output: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/efibootmgr.txt - GRUB Windows entry: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/grub_win_config.txt - GRUB Windows entry after GRUB loading: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/IMG_20161212_111004.jpg I made tests with the official GRUB package and with the one I built with the error printing patch. The patch is the following: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/0006-Fixes.patch As you can notice, I've disabled the second modification you said me (setting two parameters to 0) because that broke GRUB booting Windows in every condition. - Official GRUB, SB OFF, PreLoader OFF: Successful boot, nothing printed - Official GRUB, SB OFF, PreLoader ON: Successful boot, nothing printed - Official GRUB, SB ON, PreLoader OFF: Blocked by SB (expected) - Official GRUB, SB ON, PreLoader ON: Not working, error message: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/IMG_20161212_111340.jpg - Patched GRUB, SB OFF, PreLoader OFF: Successful boot, nothing printed - Patched GRUB, SB OFF, PreLoader ON: Successful boot, nothing printed - Patched GRUB, SB ON, PreLoader OFF: Blocked by SB (expected) - Patched GRUB, SB ON, PreLoader ON: Not working, error message: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/IMG_20161212_112657.jpg > b) try to copy bootmgfw.efi as loader.efi and start it using > PreLoader.efi just to be sure it is started? > So, I made a folder with mkdir LoaderTest && cd LoaderTest cp -i /usr/share/preloader-signed/*.efi . cp ../Microsoft/Boot/bootmgfw.efi loader.efi efibootmgr --disk /dev/sda --part 1 --create --label "LoaderTest" --loader /EFI/LoaderTest/PreLoader.efi So in the folder I have - PreLoader.efi - HashTool.efi - loader.efi -> Microsoft Boot Manager The boot was, unexpectedly, successful; PreLoader didn't ask to enroll loader.efi. I suppose this is because I had already enrolled bootmgfw.efi previously. Windows booted flawlessly anyways. > Oh, and what system is it? We apparently deal with firmware quirks, grub > itself looks OK (in the sense - the same code works in cases known so > far ...) > This is a picture of my firmware information page: https://dl.dropboxusercontent.com/u/4152736/grub_efi_debugging/IMG_20161212_120022.jpg The only thing not present in the picture is the firmware setup tool revision number, that is '3.7' > I have one more idea what we could test here, need to produce a patch, > it exceeds one liner change. > Waiting for suggestions and feedback! :) -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5 _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
