![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
On Tue, Apr 2, 2013 at 3:31 PM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Andrey Borzenkov wrote:
On Tue, Apr 2, 2013 at 11:27 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
But why would someone even try to use mokutil with the 12.3 kernel as it isn't supported?
Well, someone may want to install 3.8 kernel ...
I checked with Gary Lin for the relationship between shim with mokutil, actually, no correlation between them unless we want support MOK. I don' t know why mokutil was pushed to 12.3 repo if we don't support MOK in openSUSE 12.3
We have secure boot support in 12.3. The discussion in the bug report indicates that mokutil is needed to tell shim to call MokManager. Which in turn must be run to enroll custom keys for booting kernels signed with a key other than the openSUSE one.
We just went through it in testing patch for grub2 on secure boot system. You can enroll keys using EFI MokManager, you do not need OS level mokutil for that.
Are you saying there's a patch for grub2 that makes it call MokManger?
No. There was a patch to grub2, but to test it on secure boot system you need to enroll certificate. Package with this patch was only available from my home project, so of course it could not use openSUSE certificate. So Michael made patch to include certificate used to verify signature in grub2 package and MokManager was used to enroll this certificate. https://bugzilla.novell.com/show_bug.cgi?id=809038
Normally it would just not load a kernel signed with an unknown signature so you will never see MokManager.
I think plan was for shim to offer start MokManager if booting fails, but I do not remember code. grub2 itself does not start MokManager (may be it should; it could be easily integrated into grub.cfg). -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org