After updating my XPS 13 (9360) to current F34, with this shim, I cannot boot with Secure Boot enabled. The screen briefly shows
Bootloader has not verified loaded image.
System is compromised. halting.
and then shuts down. This happens with any kernel I try to boot. Boot with SB disabled works fine. Boot with SB enabled was working fine until I updated. fwupdmgr update does not show any available firmware updates.
Confirmed that after downgrading to shim-x86-15-8 I can boot with SB enabled.
I noticed that when doing so, something (shim?) briefly shows "Booting in insecure mode", though after boot, mokutil --sb-state shows SecureBoot enabled. Searching around for references on that, I found https://bugzilla.redhat.com/show_bug.cgi?id=1531961 , which claims that running mokutil --enable-validation would 'fix' it, though I can't find any explanation as to why. I ran that anyway, it asked for a password, I gave it one, it apparently completed OK.
System still does not boot with SB enabled and this shim, though. I don't know if it made the "Booting in insecure mode" message when booting with older shim go away yet (haven't checked, it's a lot of rebooting).
So poking through the code a bit I suspect https://github.com/rhboot/shim/commit/65be3503 , a bit, because it's a commit between 15 and 15.4 that touches user_insecure_mode. Just on the face of it - I may be misunderstanding - it looks like it adds a function (import_one_mok_state) that's intended to be called one-by-one on a bunch of variables and import them one at a time, but it unconditionally does user_insecure_mode = 0; at the start, whether it's reading the variable that might set it to 1 or not. So even if it's momentarily set to 1 when the relevant variable (MokSBState) is read, won't it then get set straight back to 0 by reading the next variable? Note user_insecure_mode is declared extern in shim.h, which AIUI makes it something like a global variable, right?
Again, I may be missing something, but if so, the same may apply to ignore_db (set by MokDBState). It also is declared as extern and set unconditionally at the start of import_one_mok_state.
I'm going to test reverting that commit if possible...
This update has been submitted for testing by pjones.
This update's test gating status has been changed to 'ignored'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
Works just fine on GA-Z170-D3H with SB Enabled.
This update has been submitted for stable by bodhi.
After updating my XPS 13 (9360) to current F34, with this shim, I cannot boot with Secure Boot enabled. The screen briefly shows
and then shuts down. This happens with any kernel I try to boot. Boot with SB disabled works fine. Boot with SB enabled was working fine until I updated.
fwupdmgr updatedoes not show any available firmware updates.Confirmed that after downgrading to
shim-x86-15-8I can boot with SB enabled.I noticed that when doing so, something (shim?) briefly shows "Booting in insecure mode", though after boot,
mokutil --sb-stateshowsSecureBoot enabled. Searching around for references on that, I found https://bugzilla.redhat.com/show_bug.cgi?id=1531961 , which claims that runningmokutil --enable-validationwould 'fix' it, though I can't find any explanation as to why. I ran that anyway, it asked for a password, I gave it one, it apparently completed OK.System still does not boot with SB enabled and this shim, though. I don't know if it made the "Booting in insecure mode" message when booting with older shim go away yet (haven't checked, it's a lot of rebooting).
So poking through the code a bit I suspect https://github.com/rhboot/shim/commit/65be3503 , a bit, because it's a commit between 15 and 15.4 that touches
user_insecure_mode. Just on the face of it - I may be misunderstanding - it looks like it adds a function (import_one_mok_state) that's intended to be called one-by-one on a bunch of variables and import them one at a time, but it unconditionally doesuser_insecure_mode = 0;at the start, whether it's reading the variable that might set it to 1 or not. So even if it's momentarily set to 1 when the relevant variable (MokSBState) is read, won't it then get set straight back to 0 by reading the next variable? Noteuser_insecure_modeis declaredexterninshim.h, which AIUI makes it something like a global variable, right?Again, I may be missing something, but if so, the same may apply to
ignore_db(set byMokDBState). It also is declared asexternand set unconditionally at the start ofimport_one_mok_state.I'm going to test reverting that commit if possible...
I filed https://github.com/rhboot/shim/pull/362 in case I'm right about the problem and the fix.
works for me
After installing this update, my XPS 13 won't boot unless I disable secure boot. Looks like it's the same issue @adamwill has.
Works only if Secureboot is disabled, don't work if enabeld, so I'm reverting karma point.
Thinkpad T480s + UEFI + SecureBoot works fine
After orientation from javierm I enabled validation on mokutil ( sudo mokutil --enable-validation ) and my system booted fine in SB.
No regressions found
Everything seems ok.
pbrobinson edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by pbrobinson.
pbrobinson edited this update.
pbrobinson edited this update.
This update has been pushed to testing.
Can confirm the Dell developer edition issue is fixed, this version boots fine.
This update can be pushed to stable now if the maintainer wishes
Works well on Skylake based desktop, Gigabyte GA-Z170-HD3 MB.
Apple Inc. MacBookPro8,2 HP Spectre Notebook Intel NUC5PPYB
This update has been submitted for stable by bodhi.
Fedora33 may need update too?
This update has been pushed to stable.