Help on booting to a 5.14.11 kernel:stable:backports kernel with secure boot? (or must I disable)?

English Install/Boot/Login
#1

I am looking for some guidance / assurance in proceeding to active an installed kernel:stable:backports kernel 5.14.11. I have ‘secure boot’ enabled in BIOS.

The laptop in secure boot, boots/runs ok with the 5.3.18 kernel (with some aspects I want to investigate by trying a newer kernel).

I installed the kernel-default-5.14.11 from the kernel:stable:backports repository on my openSUSE-LEAP-15.3 on my Lenovo X1 Carbon Gen-9 laptop (which also pulled in suse-modules-tools-16.0.11-lp153.2.1 (so to obtain suse-kernel-rpm-scriplets) replacing the previous 15.3.6-1.1 version on my laptop).

When I first rebooted, after selecting the new kernel-default-5.14.11 in the openSUSE grub menu, I was sent to a blue grub screen on “Shim UEFI key management” and asked to “Press any key to perform MOK management”.

While I was pondering this, the screen timed out, and gave me a black screen with this error:


Loading Linux 5.14.11-lp153.2.g834dddd-default ...
error: ../../grub-core/kern/efi/sb.c:151:bad shim signature.
Loading initial ramdisk ...
error: ../../grub-core/loader/i386/efi/linux.c:98:you need to load the kernel first.

Press any key to continue

I pressed a key and it sent me back to the normal green grub boot screen, at which time I selected the regular openSUSE kernel boot to a 5.3.18 kernel.

I concluded I did not know what I was doing, and I needed to research more to know what was appropriate to do next to boot to the 5.14.11 kernel.

I would like to boot to this 5.14.11 kernel, but given I am unfamiliar with this, I don’t want to mess up my install if further blue screens are encountered after I “Press any key to perform MOK management”. I suspect the next screen might say “Enrol Key from disk” or “Enrol Hash from disk”. What do I select there? My guess is “Enrol key from disk” but I prefer not to guess.

Can anyone offer any experience here?
**
Should I select “Enrol key from disk” ? And if I select that, will I encounter more menus with different selections/decisions to make? ** I prefer not to screw this us.

or is my best/only approach to disable Secure Boot in BIOS and try again?

As a precaution I have now backed up my /boot/EFI directory to a USB stick.

#2

I would enrool key from disk, but:
https://bugzilla.suse.com/show_bug.cgi?id=1191480

#3

No. Kernel installation should have created certificate enrollment request. You need to enter MokManager screen, agree to enroll certificate and provide root user password when requested (operating system root user).

Because enrollment request was already cleared, remove kernel and then install it again. Reboot, press any key and follow MokManager prompts.

P.S. I do not know where “any” key is on your keyboard :slight_smile:

P.P.S. Please avoid using bold, color etc without real need. It distracts from actual content.

#4

When you installed that 5.14.11 kernel, it should have installed a certificate in “/etc/uefi/certs”. There are probably several certificates there. The one installed by the kernel install will not have “-shim” as part of the name. You can probably guess which one it was by the timestamp on the file.

Enroll that certificate:

mokutil --import FILENAME

(Run that as root). If you add “–root-pw” to that command line, then it will use the root password for the enroll. Otherwise it will prompt you for a one-time password.

On reboot, you should get that blue screen again, to complete the enroll request.

#5

Unfortunately, I proceeded before all the replies to this thread were given. I tried “enroll key from disk” and it failed.

For the curious, this is what I did which failed to work:[INDENT=2] I de-installed the 5.14.11 kernel, rebooted to 5.3.18 kernel, re-installed 5.14.11 kernel, rebooted and selected the 5.14.11 at boot. It presented me this menu where I had to choose from:

[/INDENT]
[INDENT=3]* continue boot

  • enroll MOK
  • enroll key from disk
  • enroll hash from disk[/INDENT]
    [INDENT=2]
    I selected ‘enroll key from disk’

I then obtained this:
[/INDENT]
[INDENT=3]“Select Key” - “The selected key will be enrolled into the MOK database. This means any binaries signed with it will be run without prompting. Remember to make sure it is a genuine key before Enrolling it”.
[/INDENT]
[INDENT=2]
After pressing any key, I then obtained this list of directories:

[/INDENT]
[INDENT=3]* EFI/

  • BOOT/
  • System Volume Information/
  • $RECYCLE.BIN/[/INDENT]
    [INDENT=2]
    Note there is no option to navigate to a higher level directory. I chose EFI and obtained this:

[/INDENT]
[INDENT=3]…/
Microsoft/
Boot/
opensuse/[/INDENT]
[INDENT=2]
I chose ‘opensuse/’

I was then given this choice:

[/INDENT]
[INDENT=3]* MokManager.efi

  • grub.efi
  • shim.efi
  • boot.csv
  • grub.cfg
  • grubx64.efi[/INDENT]
    [INDENT=2]
    I chose ‘shim.efi’ which did not work, as I obtained this:

[/INDENT]
[INDENT=3]Unsupported Format; Only DER encoded certificate (*.cer/der/crt) is supported. OK.[/INDENT]
[INDENT=2]
Clearly I had no clue as to what was best. I clicked OK and I was back to here:

[/INDENT]
[INDENT=3]* continue boot

  • enroll MOK
  • enroll key from disk
  • enroll hash from disk[/INDENT]
    [INDENT=2]
    I selected ‘continue boot’ and as expected, I obtained the same error as before.
...
error: ../../grub-core/kern/efi/sb.c:151:bad shim signature.
Loading initial ramdisk ...
error: ../../grub-core/loader/i386/efi/linux.c:98:you need to load the kernel first.

Press any key to continue

[/INDENT]

So back to the drawing board … so to speak …

By the date time stamp in /etc/uefi/certs directory, there is only one file with .crt entitled "6A4E915C.crt " that is associated with today

Run that while being in a boot from the 5.3.18 kernel? That is counter intuitive to me, albeit I confess I have no clue. What does that do? The man page says it manipulates machine owner keys which is not specific enough for me to understand. … I have questions like, if a key is created/imported - where does it then go? How will it be named ? … and there are probably more questions I should ask but I am not smart enough to know the questions. …
.

I am still puzzled here. Where do I navigate to? As seen from the above, there will be a selection or will the menu selections have changed after running ‘mokutil’.

…
I actually surfed looking for a guide through all these different menus, and I failed to find such. :frowning:

#6

Enroll MOK

#7

Yes, that’s fine. What that command does, is leave a message in NVRAM. That message is picked up by “shim” on your next boot, which then loads “MokManager” to enroll the key.

As said by arvidjaar, you should go with the “enroll MOK”.

#8

Thankyou for the help.

Thanks to your help, I am now typing this from LEAP-15.3 running the 5.14.11 kernel. For info:


oldcpu@localhost:~> uname -a
Linux localhost 5.14.11-lp153.2.g834dddd-default #1 SMP Sun Oct 10  08:34:34 UTC 2021 (834dddd) x86_64 x86_64 x86_64 GNU/Linux

DETAILS (for any who may be curious):

The first time when running LEAP-15.3 from the 5.3.18 kernel (also with the 5.14.11 kernel installed from before) when I tried ‘mokutil’ command to import the key, I did so from /home/oldcpu, and of course it failed (with an error message it could not find the file status). I was not thinking, as when running the command the bash shell either needed to be in the /etc/uefi/certs subdirectory, or the path was needed. So I changed to the /etc/uefi/certs subdirectory and tried again with:


localhost:/etc/uefi/certs # mokutil --import 6A4E915C.crt --root-pw

That gave no error message, just a return of the root prompt, which I took as a good sign. So I rebooted and immediately obtained this in a blue screen:

Shim UEFI key management" and asked to "Press any key to perform MOK management"

I immeadiately pressed a key.

I was then presented with this menu (as before) where I had to choose:[INDENT]* continue boot

  • enroll MOK
  • enroll key from disk
  • enroll hash from disk
    [/INDENT]

This time I chose “enroll MOK”. That then presented me with this screen:[INDENT] * View key 0

  • Continue
    [/INDENT]

I had no idea what “View key 0” was for, so I elected to ignore that and I selected “continue” … That then presented me with this:[INDENT] Enroll the key(s)?
.

  • No
  • Yes
    [/INDENT]

I selected “Yes” and I was prompted with a blue screen asking for a “Password”. I entered the root password. I then obtained this screen:[INDENT]Perform MOK management
.

  • reboot
  • Enroll key from disk
  • Enroll hash from disk
    [/INDENT]

I already knew that 'enrolling key from disk was the wrong approach, … and I decided if my previous actions (with entering the root password) were correct, then a reboot likely appropriate, so I selected ‘reboot’.

The PC rebooted, I selected to boot to the 5.14.11 kernel in the grub menu, and this time I had a boot success to the 5.14.11 kernel.

I am now posting immediately after that. I have yet to explore this new kernel, … and pretty much all the kernel related apps I have still installed are associated with the older 5.3.18 kernel, where I may wish to update all those other kernel related apps (but I have not done so yet). I suspect I also may wish to update the intel-media-driver app as well to a newer version.

Many thanks again to all on this thread for your help. I was DEFINITELY out of my comfort zone here … and maybe thats a good thing.

I was pleased (thanks to your help) that I was able to do this without disabling the secure boot.

#9

That would have given information about the key - mostly a screen of hexadecimal numbers. If you are not sure what key you are enrolling, you could use this to check – except that you probably don’t have anything to check it against.

And after viewing the key, there would have been another prompt to enroll it.

And, yes, after all that choosing “reboot” was the right step.

I was confused by these MOK screens the first few times. It is a learning experience. You will be more comfortable next time.

#10

and pretty much all the kernel related apps I have still installed are associated with the older 5.3.18 kernel

Here are some kmps for kernel:stable:backports:
https://download.opensuse.org/repositories/Kernel:/stable:/Backport:/KMP/standard/

But no nvidia, you have to build it the hard way (which is no hard way)…

Otherwise post your missing kmps.

#11

Thanks. I don’t think I am currently using any ‘kmps’ although I note I do have installed at present:

ipset-6.36-3.3.1.x86_64
libipset11-6.36-3.3.1.x86_64

where there are newer versions of those apps in the Backport:KMP directory you pointed out. Its not clear to me there is a benefit to update those from the LEAP-15.3 OSS repos to the Backport:KMP repos version. … At present, I still wish to retain the ability to reboot to the older 5.3.18 kernel, so I am being cautious as to what I update. For example, at present, I still have many older 5.3.18 kernel devel/souce apps installed (where there are 5.14.11 versions if I wished to install those instead).

If I decided to install virtualbox and run it under the 5.14.11 kernel, I see that Backport:KMP might be of use.

The graphics in this Lenovo is Intel - so no nvidia hardware to the best of my knowledge.
.

#12

Try to use Mesa 3D from Experimental branch (X11:XOrg repo).
Also you may want to perform Full repository Vendor change to X11:XOrg repo.

#13

As I noted in a previous thread, I am a very conservative GNU/Linux user. This Lenovo X1 Carbon-Gen9 is possibly the newest hardware I have used (relative to the state of GNU/Linux support). Adding new more cutting edge software really takes me out of my comfort zone.

I note at present my my openSUSE-15.3 has the following:

  • intel-media-driver-21.2.3-lp153.33.2 <<<< I updated this shortly after I went for the 5.14.11 kernel from kernel : backport : stable
  • Mesa-20.2.4-57.13

I note in the X11 : /XOrg : repository

  • intel-media-driver-21.3.4
  • Mesa-21.2.3

I also checked github, where the most current Mesa is 21.2.4 (released around 14-October-2021). But the 21.2.3 in the X11 : / XOrg repos is very new (released 30-Sep-2021 from github). In contrast the Mesa-20.2.4 in my openSUSE LEAP-15.3 was released in github on 5-Dec-2020.

I then started looking at the change history between v.21.2.3 (in X11 : XOrg repos) and the 20.2.4 on my LEAP-15.3. I searched mostly for i915 and iris (as my TigerLake CPU in the X1 Carbon Gen9 has Iris graphics). There were some i915 bug-fixes/updates and MANY iris bug-fixes/updates. Some of which appear to prevent crashes …

So I am tempted to update here, but this really takes me out of my comfort zone.

If an update to that repos ‘breaks the gui’ then I either have to try to recover from runlevel 3 (which will be a pain) or do a new install (which would also be a pain).

Its food for thought as I try to decide ’ to update ? ’ - ’ or not to update’ … .
.
.

#14

I upgraded today from the 5.14.11 to the 5.15.7 kernel.

Prior to upgrading I made notes as to what I went through last time, such that when I rebooted I would know what to do.

Much to my surprise, on my reboot, I did not go through any of what I went through before. The laptop gave me a grub screen where I select LEAP-15.3, and after selecting that there was a straight boot to the 5.15.7 kernel.

One other surprise was my bluetooth mouse is not currently working in ‘bluetooth mode’ and I had to switch it to wireless mode (inserting the wireless transmitter/receiver into one of the laptop’s USB ports). This will give me something to investigate (I am running a KDE desktop).

#15

Bluetooth is working here.

So maybe a Problem with your mouse?

Try to delete the Profile and pair it once more?

#16

Thanks for the suggestions. I note bluetooth doesn’t work at all now with 5.15.7 kernel on my Lenovo X1 Carbon gen9. My bluetooth Bose headphones also don’t work with the 5.15.7 kernel. Repairing doesn’t work. bluetoothctl indicates no controllers.

Rebooting to the 5.14.11 kernel and bluetooth works fine. This is from the 5.14.11 kernel:

oldcpu@X1-Carbon-G9:~> bluetoothctl
Agent registered
[Bose SoundSport]# devices 
Device 2C:41:A1:42:74:3B Bose SoundSport 
Device F6:71:7A:7D:59:9C BT5.0 Mouse
[FONT=monospace][Bose SoundSport]# list 
Controller 10:3D:1C:C4:27:BD X1-Carbon-G9 [default]

[/FONT]

For the above in the 5.14.11 kernel, I was paired with the Bose headset, but not paired with bluetooth mouse (mouse is in wireless mode for this test with 5.14.11).

When booting to 5.15.7 kernel, the 5.15.7 finds no devices - and sees none when pairing attempted. Here is from the 5.15.7 kernel:


oldcpu@X1-Carbon-G9:~> bluetoothctl 
Agent registered 
[bluetooth]# list 
[bluetooth]# devices 
No default controller available 
[bluetooth]#

Surfing and I see there are bug reports on bluetooth in the 5.15.x kernels, which is gradually being fixed (there were some fixes that worked for some in the 5.15.4 kernel according to internet, but not working for all commenting in the bug reports). For example: https://lore.kernel.org/regressions/CAJvGw+AJ5dHSb50RtJHnjbhMVQa+rJgYznFV4t-iaO0qx+W-jw@mail.gmail.com/T/#u

For some users a complete shutdown - wait some minutes, then start the laptop, and bluetooth in the 5.15.x works … however after a subsequent reboot it doesn’t work. For others, like me, a shutdown doesn’t work.

Further , the kernel fixes applied to date (up to 5.15.7 kernel) do not work for my X1 Carbon gen-9.

Its not the end of the world - as I have wired headphones (the laptop does have a headphone output port) and my Bluetooth mouse has a switch to allow me to change it to a wireless mode. That uses up a USB port, but I have a USB hub.

This ‘bluetooth issue’ will be something for me to track.

#17

I found the openSUSE bug report on this issue: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124

#18

I installed the updated to the 5.15.10-lp153.2.g85804f3-default on my Lenovo X1 Carbon gen9 (running LEAP-15.3) and bluetooth is now working again with both my bluetooth mouse, and my Bose Soundsport earbuds. :slight_smile: