On Tue, 2023-03-07 at 17:26 +0000, Joe Salmeri wrote:
Hi Larry,
I was hoping that you would chime in.
The MOK BlueScreen comes up during the reboot just as you describe and I proceed to enroll the key and no errors are reported.
After reboot and enrolling the key
mokutil --list-enrolled shows the key (whereas before the reboot mokutil -- list-new showed that the key was new but not enrolled yet)
I have also done the mokutil --delete to remove the key, rebooting and removing via the MokManager blue screen and then repeating the process of
compile vmmon and vmnet generate key sign vmmon and vmnet with the kernel mokutil --import *.der file reboot enroll boot mokutil --list-enrolled shows the key
BUT....
kernel still complains that the modules are unsigned, despite, modinfo showing that they are.
In an earlier message, I listed the exact steps I did, could you please look at that and tell me what step I am missing?
Thank you!
This is very similar (probably not a surprise ;)) to my experience with NVIDIA 530.30.02 .run install. It's been working fine but refuses to work w/ 6.2.1 ... I opened a ticket[1] when 6.1.12 was giving me hardlock headaches and switching to what was current at the time in Kernel_stable allowed me to update (the kernel, at least) and carry on. Something about the Intel devices in this laptop (and really only this laptop; other systems w/ Intel h/w are fine) seem to give random TW kernel's fits. I see the same thing you do where my process has always worked in the past but flat out refuses to work w/ 6.2.1 (I even see that same message when I do something like 'modprobe nvidia_drm') and works just fine w/ 6.2.0 ... I also put a bit too much trust in 6.2.1 and allowed it to uninstall the Kernel_stable 6.2.0 (which removed the MOK key for it) which immediately bit me in the butt when I wanted to use snapper to roll back. Thankfully snapper still saved me by making a pre-bbswitch-install snapshot available and I was able to grab the 6.2.0 kernel items from download.opensuse.org/history which used "CN=openSUSE Secure Boot CA" ... I'm not sure what 'lockdown patches' are adding and I'm not arguing against it - but it did come out of nowhere doesn't seem to have an intuitive solution for those of us who build certain kernel modules (I have 2, this NVIDIA one and on for 8852au). I dual boot this Dell laptop w/ Win11 and while it doesn't appear having SecureBoot enabled is a REQUIREMENT, it's all been working fine until 6.2.1 so I don't feel like disabling it is the solution here. [1]: https://bugzilla.opensuse.org/show_bug.cgi?id=1208444 -- ~ Scott Bradnick |- Windows Subsystem for Linux (WSL) Developer |-- Tumbleweed: |--- Dell Precision 5540 [NVIDIA Quadro T1000] (x86_64) |--- O-DROID H2+ [UHD Graphics 600] (x86_64) |--- IceWhale ZimaBoard 832 [Intel HD Graphics 500] (x86_64) |--- 2x Raspberry Pi 4 Model B Rev 1.2 (aarch64) |--- 1x Raspberry Pi 3 Model B Rev 1.2 (aarch64) |--- WinBook TW100 (x86_64) https://keys.openpgp.org/ :: DBC5AA9A2D2BAEBC