I try to install my fresh system as follows:
[LIST=1|INDENT=1]
/dev/sda = 4TB (~3.65 TiB), Single BTRFS for the various OS/distro installs.
/dev/sdb = 2TB (~1.84 TiB), Single BTRFS for my precious data.
/dev/sdc = 150GB (~149.5 GiB), UEFI SecureBoot.
p1 = 1GiB (ESP), because booting with Systemd-boot will need the kernels and ramdisks in the ESP, plus EFI-Shell, plus efi-tools, etc.
p2 = 64GiB (swap), motherboard has 32GB RAM(DIMMS) installed and i want to be able to use hybernation etc…
p3 = rest ~84GiB as BTRFS (/home) to ease reinstalls in /dev/sda when needed…
[/LIST]
Soo…Now comes my problems i face at moment.
My Wifi does not seem to be working.
+0.001525] b43-phy0: Broadcom 4352 WLAN found (core revision 42)
+0.001165] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)
+0.000037] b43: probe of bcma0:1 failed with error -95
+0.000021] Broadcom 43xx driver loaded Features: PNLS ]
My BlueTooth does not seem to be working. (Which i can most probably fix using a firmware file i have inside /dev/sdb, that worked in my previous distro)
Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0b05-17cf.hcd not found
My videocard does not work with the nVidia drivers in Leap.
My videocard does work with the nVidia drivers in TW but is not signed…
I don’t get the MokManager screens in Suse (and neither did in *ubuntu, where i had to manually add the cert in the MokList using efitools.)
Where is the cert that is used in suse, so i can manually add it to the MokList using efitools?
This post is still a WIP and will be updated as needed…
The general advice for broadcom wifi is:
1: Add the packman repo if you have not already done that:
zypper ar -f -n packman --priority 90 http://packman.inode.at/suse/openSUSE_Tumbleweed/ packman
2: Install broadcom-wl from packman. It’s easiest to use Yast Software Management for that.
Then reboot, and see if WiFi starts working.
You might also need to disable secure-boot for this to work (assuming that you use UEFI). That’s because the signature on the broadcom module is being checked, but the module is probably not signed by an openSUSE signing key.
Thanks for the info provided and the Wifi and Nvidia drivers seem to work when SecureBoot is disabled while booting Leap.
And works in Tumbleweed regardless of SB-state but logs a warning about it, must be because the kernel does not enforce module signatures…
But that is ofcourse not the right-thing to have in both versions, why are these modules not signed for SB at install?
I noticed that the dkms package is not even installed by default, which is meant for automatic kernel-module signing IIRC.
At least that’s what happens in *ubuntu distros.
Still want to know where the certificate is that is meant to be used to sign the kernel modules, anyone any idea?
Because i want to boot with SecureBoot mode enabled…
Oh PS:
Why do i get a GRUB command-line without any errors after installing these kernel modules?
I have to type “exit” to continue, which is very weird and frustrating…
(Not to mention that i want to switch to Systemd-boot as soon as possible and drop grub)
The boot.txt files are used to create a combined boot.csv file by a script i created for this purpose…
My script automatically adds the UEFI boot entries accordingly.
I can’t check on that because I am not using either nvidia or broadcom drivers.
It is my understanding, that the nvidia drivers are signed. But I think they are signed with a different key. At some time during boot, you probably got a blue screen asking you to add a key. And if you selected “continue” then the key was not added. That could be the problef for nvidia drivers.
For the broadcom drivers – those come from packman. As far as I know, the packman maintainers do not have access to the openSUSE signing key. So you would need to create your own key and sign the modules yourself with that.
I noticed that the dkms package is not even installed by default, which is meant for automatic kernel-module signing IIRC.
At least that’s what happens in *ubuntu distros.
I think you only need “dkms” if you are building the modules yourself. If you are installing prebuilt modules, you should not need it.
Still want to know where the certificate is that is meant to be used to sign the kernel modules, anyone any idea?
Because i want to boot with SecureBoot mode enabled…
The key for checking signatures should be in “/etc/uefi/certs”. The signing key is, I hope, carefully protected by openSUSE administrative people. If you want to sign modules yourself, you will need to create your own signing key.
It is probably too blanket statement. sd-boot does not actively use shim interface to verify signature, that’s correct. In secure boot environment it expects unified image which combines loader, kernel, initrd and command line in single EFI executable. This executable can be signed and itself loaded e.g. by shim. Unfortunately, it cannot be shipped by distribution for obvious reasons and can only be generated and signed on end-user system (or user must enroll hash of resulting binary). dracut supports it.
As you can read in Bug 1175210 - [Leap 15.2] [x11-video-nvidiaG05] Drivers not working with SecureBoot enabled](1175210 – [Leap 15.2] [x11-video-nvidiaG05] Drivers not working with SecureBoot enabled), i didn’t even get a blue screen asking to add “the key” (which is actually a certificate and not a key)
Furthermore the nVidia kernel-module is compiled at the machine that is installing the nVidia drivers, thats how nVidia provides its drivers.
Anyway it seems there is something wrong with this whole that’s why i participated on the bug tracker and posted the above bug report…
That’s correct for both Systemd-boot and grub and others alike, because that is the job of the shim.
I use the shim in the same way as grub does eg, let shim chain-load Systemd-boot directly without grub in between them
Well, actually it does but you are right - current sd-boot also supports shim validation (by installing EFI security policy hooks, so any image will be subject to shim verification in addition to built-in firmware verification).
Hmm … current shim also supports installing security policy on its own. SUSE builds shim without this support.
Hmmm interesting, not quote sure what you exactly mean by that because the security policy is something the UEFI provides and shim just proxies requests to it while adding support for using the MoKList in the chain of trust AFAIK…
(A little simplified explanation of shim workings there ofcourse)
Do you mean current shim actually replaces/adds the security policy if the machine has no UEFI or missing/old SecureBoot functionality?
It is possible to override code implementing security policy by custom implementation. Try to actually read and understand what code you yourself pointed at does.
Ok so your answer to my last question is that the current shim indeed replaces the security policy provided by the UEFI…
(If i didn’t understand the code i would not have asked that question ;), you just didn’t understand my question which is no problem as it is solved now)
