You are not logged in.
I have a successful secure-boot uefi configuration, shim is pre-loading refind, which in turn loads a uefi stub loader (containing hard-coded kernel parameters generated by sbupdate) which finally loads my kernel, right? Everything is automatically signed using sbupdate. It's pretty cool.
Any idea why the stubloader will boot the system perfectly normal from shim/refind in secure boot mode, but with secure boot mode disabled fails? (The stub loader craps out and drops to emergency shell (before luks encrypt hook, it never does ask me to enter my luks password.) Meanwhile, booting the kernel from refind directly (bypassing the stub loader) works just fine in both secure and non secure boot modes.
This one has me confuzzled.
Basically, I don't get why the stub loader works in secure-boot mode, but not in the less-strict non-secure uefi boot mode!
Edit: Could this be a refind bug possibly where refind (in uefi non-secure boot mode) is not passing the proper kernel parameters from efi stub loaders to the kernel? How do I debug this? I have never reported a bug before, but if I need to pass this on to a refind developer, maybe I can help do that.
Last edited by thebardian (2017-07-12 22:31:24)
Offline