Most of the messages, including all of the error messages and the doubled-up \EFI\bootit pathname element, come from Shim, not from rEFInd. It looks to me as if the follow-on Shim has become confused about its boot path, and is doubling up that \EFI\bootit element, thus causing the problem. I recall running into this sort of thing during rEFInd's development; I had to be very careful about when to pass a leading \\ to the EFI when specifying a filename. It's conceivable that this is another instance of this problem occurring; or it could be that rEFInd is doing exactly what it should and that Shim just can't handle this boot procedure (Shim-to-rEFInd-to-Shim). I'll do some experimentation myself, but in the meantime I have two suggestions:
Don't use a manual boot stanza. rEFInd should be able to auto-detect a boot loader in the EFI\bootit directory, so a manual boot stanza should be unnecessary. The worst-case scenario is that the boot entry won't be named what you like, but that's a small problem compared to an inability to boot the item.
Don't use two Shims. The first Shim should suffice, possibly combined with a MOK corresponding to the key in the second Shim (or some other key, if you re-sign the follow-on boot loader yourself).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tell me please what are the shim in nature (I only know fedora and ubuntu).
And how to find out what internal keys they support?
Can I make and sign shim myself?
I noticed two problems.
1. On some computers, the MOK utility (mmx64.efi - ubuntu, MokManager.efi - centos) does not accept keys if the file name consists of one word. It is solved by renaming key on refind-self-signed.cer. It's strange, but it's true.
2. After exit of the gdisk utility (1.0.4), the boot stops in the SeсureBoot mode for programs with MOK keys. This is not a refind problem, it's in gdisk.
P.S. I'm testing bootit uefi 1.02 - the second shim works there.
Last edit: Viktor Ostapchuk 2018-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Secure Boot on.
shim (ubuntu) -> refind (as grubx64.efi) -> shim2 (bootit)
When I try to load another shim, I get an error message.
https://i.imgur.com/3gZfIOs.png
How can I fix this?
Thank you.
Last edit: Viktor Ostapchuk 2018-07-06
Most of the messages, including all of the error messages and the doubled-up
\EFI\bootitpathname element, come from Shim, not from rEFInd. It looks to me as if the follow-on Shim has become confused about its boot path, and is doubling up that\EFI\bootitelement, thus causing the problem. I recall running into this sort of thing during rEFInd's development; I had to be very careful about when to pass a leading\\to the EFI when specifying a filename. It's conceivable that this is another instance of this problem occurring; or it could be that rEFInd is doing exactly what it should and that Shim just can't handle this boot procedure (Shim-to-rEFInd-to-Shim). I'll do some experimentation myself, but in the meantime I have two suggestions:EFI\bootitdirectory, so a manual boot stanza should be unnecessary. The worst-case scenario is that the boot entry won't be named what you like, but that's a small problem compared to an inability to boot the item.Thank you. I see. Just added more keys.
Tell me please what are the shim in nature (I only know fedora and ubuntu).
And how to find out what internal keys they support?
Can I make and sign shim myself?
I noticed two problems.
1. On some computers, the MOK utility (mmx64.efi - ubuntu, MokManager.efi - centos) does not accept keys if the file name consists of one word. It is solved by renaming key on refind-self-signed.cer. It's strange, but it's true.
2. After exit of the gdisk utility (1.0.4), the boot stops in the SeсureBoot mode for programs with MOK keys. This is not a refind problem, it's in gdisk.
P.S. I'm testing bootit uefi 1.02 - the second shim works there.
Last edit: Viktor Ostapchuk 2018-07-07
Hmm...
Working! Just deleted the slash!
Last edit: Viktor Ostapchuk 2018-07-06