help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB can't chainload Windows under Secure Boot


From: Andrei Borzenkov
Subject: Re: GRUB can't chainload Windows under Secure Boot
Date: Sat, 10 Dec 2016 22:11:24 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

10.12.2016 21:29, Giovanni Santini пишет:
> Il 10/12/2016 16:01, Andrei Borzenkov ha scritto:
>> No, that's OK. The error is EFI_INVALID_PARAMETER which is rather
>> unexpected at this point.
>>
>> Stab in the dark - could you try to change loading from
>>
>>   status = efi_call_6 (b->load_image, 0, grub_efi_image_handle, file_path,
>>                        boot_image, size,
>>                        &image_handle);
>>
>>
>> into
>>
>>
>>   status = efi_call_6 (b->load_image, 0, grub_efi_image_handle, file_path,
>>                        0, 0,
>>                        &image_handle);
>>
>> I understand that you are loading file from ESP, so it should be
>> directly accessible by firmware.
>>
>> And yes, please use PRIxGRUB_UINT64_T instead so code is printed in hex,
>> it is more readable.
>>
> 
> So, changes were made, and the error become:
> 800000000000000e

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).

b) try to copy bootmgfw.efi as loader.efi and start it using
PreLoader.efi just to be sure it is started?

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 ...)

I have one more idea what we could test here, need to produce a patch,
it exceeds one liner change.

> I am adding the additional patch I've created for testing, just to be
> sure I'm doing stuff properly.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]