These all assume that you sign the first item launched with the Secure Boot keys you generate, and the last three also require that you sign your kernel with the same keys. The first three will launch kernels signed with whatever keys are built into shim or supported by MOKs you've loaded into your firmware. All but the first require a 3.3.0 or later kernel with EFI stub support. Since you're replacing your firmware's MS keys, IMHO there's not much point to the shim->rEFInd->kernel and patched shim->kernel paths; shim doesn't add anything to either path.
GRUB 2 does support chainloading another EFI boot loader. If it does so using standard EFI system calls, in theory a GRUB2->kernel path would work *if* you launch the kernel via GRUB2's "chainloader" command rather than the "linux" command and if your kernel is 3.3.0 or later with EFI stub support. My one attempt (months ago) to do this without Secure Boot failed, but I never tried to track down what went wrong; it could have been a simple typo in my configuration file. If this could be made to work, though, it might provide a seventh option that would work exactly as you want it to.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2012-12-10 06:37 pm (UTC)* shim->F18's GRUB2->kernel
* shim->rEFInd 0.5.0->kernel
* Patched shim->kernel
* Any rEFInd->kernel
* gummiboot->kernel
* kernel direct (via EFI boot manager)
These all assume that you sign the first item launched with the Secure Boot keys you generate, and the last three also require that you sign your kernel with the same keys. The first three will launch kernels signed with whatever keys are built into shim or supported by MOKs you've loaded into your firmware. All but the first require a 3.3.0 or later kernel with EFI stub support. Since you're replacing your firmware's MS keys, IMHO there's not much point to the shim->rEFInd->kernel and patched shim->kernel paths; shim doesn't add anything to either path.
GRUB 2 does support chainloading another EFI boot loader. If it does so using standard EFI system calls, in theory a GRUB2->kernel path would work *if* you launch the kernel via GRUB2's "chainloader" command rather than the "linux" command and if your kernel is 3.3.0 or later with EFI stub support. My one attempt (months ago) to do this without Secure Boot failed, but I never tried to track down what went wrong; it could have been a simple typo in my configuration file. If this could be made to work, though, it might provide a seventh option that would work exactly as you want it to.