Failed to enroll key for refind_x64.efi in Hashtool.efi when using Preloader

[PaTTeeL]

Hello ! Need help ! For BitLocker , I want to work under secure boot mode , I've boot from preloader in secure boot turned off , and use hashtool to enroll key from file , but when I selected refind_x64.efi , it shows "Hash Tool report ERROR" "Hash failed (is efi binary valid?):(2)" "Invalid Parameter" , then press "ok" to exit, but when I choose Grubx64.efi , the program passed, and works ok under secure boot mode.
But rEFInd is the only EFI boot manager that support touch screen for my Surface Pro 3, and which support gui boot menu. I've tried shim to fix it , but to boot android x86 with 32bit under secure boot mode , it means shim->rEFInd->preloader->loader.efi(grubx64.efi)->android-x86-kernel , and it fails. I think user preloader->rEFInd->loader.efi(grubx64.efi)->android-x86-kernel should be ok , but hash tool shows failed , so what can I do for loading system under secure boot mode and user android-x86 system?
Is there any problem when using preloader ? Or can rEFInd x64 support loading ia32 kernels ?
My Computer is Surface Pro 3
rEFInd Ver : 0.11.4
BTW , when I use rEFInd to load gptsync_x64.efi or gdisk_x64.efi it also shows error , says unsupported efi program , but shellx64.efi works fine , should be the same bugs ?

[Roderick W. Smith]

First, you might try a different rEFInd binary. I build binaries using both TianoCore EDK2 and GNU-EFI (see the downloads page for links to both varieties). It's possible that one will work but the other won't, for whatever reason. If you can get rEFInd to run with Secure Boot disabled, you can learn which you've got by checking the About/Info screen.

Second, PreLoader and HashTool are definitely "the road less travelled," and as such, may be more prone to problems. You may have better luck with Shim and its MokManager.

Finally, some UEFIs just plain have flaky Secure Boot implementations. I could never get it to work with an HP EliteDesk micro-desktop system I own, for instance. It's been a while since I tried, but IIRC, the symptoms were similar to what you're reporting -- I couldn't get keys or hashes to enroll. If you think this is the issue, you could check to see if the computer's/motherboard's manufacturer has an updated firmware available -- but too often, they just shrug their shoulders and move on to the next model before they fix all their firmware bugs.

[PaTTeeL]

Thank you for respond.
I've tried the binaries build by GNU-EFI , it works correctly when using HashTool for PreLoader , but it seems driver mods in drivers_x64(like ext2_x64.efi , ext4_x64.efi , ntfs_x64.efi , etc) still built by TianoCore EDK2(files got the same hashs in both packages) ,and when I'm trying to boot rEFInd via PreLoader , it reports error as the picture 1 . So where can I find the GNU-EFI based drivers or could you please fix it ?
BTW , the gptsync_x64.efi or gdisk_x64.efi still reports error when loading by EFI manager , which shows "Error: Unsupported while loading gdisk_x64.efi" in rEFInd & "error: cannot load image" in GRUBx64 , but memtest86.efi & shellx64.efi works fine at the same time . So could be the same problem while built by TianoCore EDK2 ?

[Roderick W. Smith]

Long ago, the drivers built only with TianoCore, not with GNU-EFI, and IIRC, my scripts to build the GNU-EFI .zip file as part of my release process pre-date the time when the drivers could be built with GNU-EFI, so they copied the TianoCore-built drivers. I'd forgotten that fact. I've built the drivers and gptsync manually with GNU-EFI for you:

https://www.rodsbooks.com/drivers-gptsync.zip

Note also that installing unnecessary drivers can cause problems. They are officially in beta test, and so may contain bugs that can hang the system; and even absent bugs, loading them takes time. Thus, I recommend installing only the driver(s) you really need.

That new .zip file contains drivers and gptsync_x64.efi binaries built with GNU-EFI. I don't have an easy way to rebuild gdisk_x64.efi in another way, since that's part of the GPT fdisk project, which uses entirely different build scripts. That binary is already built with GNU-EFI, anyhow, so the problem with it is not related to TianoCore. For that matter, the gptsync_x64.efi binary in the GNU-EFI .zip file may well have been built with GNU-EFI, too, so I'm not sure the build in the drivers-gptsync.zip file will help. You could always try the TianoCore build of that binary if the GNU-EFI build fails.

Overall, it sounds like your computer's Secure Boot implementation is a bit on the flaky side. I've seen this sort of thing before, and short of getting an updated firmware (which might or might not be available), I don't know of a real fix. At best, you can work around the problem by cherry-picking the binaries that do and do not work. This can be a pain. It's worth checking with the computer's or motherboard's manufacturer to see if a firmware (they'll likely call it a "BIOS") update is available.

[PaTTeeL]

Thx for the rebuilt binary , it works by turn off secure boot , but cannot pass the signature . But recently , I found Android x86 supports bootup under secure boot , I've solve the problem by using shim->rEFInd(TianoCore)->GRUB2->Android Kernel , thank you very much for the support.

BTW , after checking the latest firmware of Surface Pro3 , I've tested gptsync_x64.efi in my Surface Pro3 , still fails . It seems the machines does not support run gdisk/gptsync in uefi , thanks anyway .