OpenSuse Leap misc installation hints
Some tweaks to make OpenSuse work as expected. This was done with version 15.4 but usually these topics are to be done for every new version. I list them here to not forget how to fix the issues.
Make dmesg work
dmesg does not work for non-root users, it needs a tweak to do this.
sysctl -w kernel.dmesg_restrict=0
bash -c 'echo "kernel.dmesg_restrict = 0" >> /etc/sysctl.d/10-dmesg-non-root.conf'
See https://forum.ubuntuusers.de/topic/schikane-mit-dmesg/
Make external soundbox work via bluetooth
This is another ugly story.
If the home directory was moved from another machine on a new machine,
first remove ~/.config/pulse to get rid of old configs, which usually do not work anymore.
My soundbox was detected and conected via bluetooth, but no sound. It used the “Headset Profile”.
I solved it by editing /etc/bluetooth/main.conf
# Add next line
Disable=Headset
# Search and uncomment next line
Name = BlueZ
Restart bluetooth
service bluetooth restart
If no sound comes, continue to check pulseaudio
pavucontrol
Check under “Configuration” if the profile used for the target sound device is “A2DF”. Stay away from HFP profile. Also check used Codec. For my case, I need to select SBC. The other codecs gave no sound at all.
I also installed another package (blueman), but guess it is not needed to solve this issue.
Forbid to move windows to primary screen after screen saver blanked 2nd screen
See screenshot. Stop “KScreen 2” and forbid to restart it again.
Access to Google Drive
- Install Gnome Nautilus
- Install Gnome Control Center
- Install Gnome Keyring (required to keep account data for Google account)
Execute gnome-control-center and add account data for Google.
If you have not yet installed gnome-keyring, you will not be able
to store the account data.
Then start nautilus, and add Google Drive.
See: https://sites.google.com/site/installationubuntu/home/ubuntu-16-4-lts/google-drive-in-nautilus
Install youtube-dl via docker image
There is an annoying bug in youtube-dl that prevents it to work.
Somehow this can be fixed with python modules etc. but that needs much effort.
Simplest thing is to use a docker image with that tool inside it.
https://hub.docker.com/r/mikenye/youtube-dl
Follow there instructions:
Download image docker
pull mikenye/youtube-dl
Define alias:
alias yt-dl='docker run \
--rm -i \
-e PGID=$(id -g) \
-e PUID=$(id -u) \
-v "/home/dennis/dwhelper":/workdir:rw \
mikenye/youtube-dl'
And just use it. The alias cannot be used inside shell scripts, so maybe a script for that command would be the better approach.
Fix UEFI boot order after installing Linux over some Windows 11 installation
This is an ugly story.
I bought again an HP notebook that came with some useless Windows 11. I installed OpenSuse Leap 15.4. But when rebooting, the Windows UEFI boot manager took control and complained. It still was possible to boot into Linux, but I wanted to get rid of this zombie.
Check the boot order with efibootmgr tool:
efibootmgr
BootCurrent: 0001
Timeout: 5 seconds
BootOrder: 0002,0001,0000,2001,3002,2002,2004
Boot0000* openSUSE
Boot0001* opensuse-secureboot
Boot0002* Windows Boot Manager
Boot0003* USB CD/DVD ROM Drive (UEFI) (Single Flash Reader)
Boot2001* EFI USB Device
Boot3002* Internal Hard Disk or Solid State Disk
Fix order:
efibootmgr -o 0,1,2001,3002
BootCurrent: 0001
Timeout: 5 seconds
BootOrder: 0000,0001,2001,3002
Boot0000* openSUSE
Boot0001* opensuse-secureboot
Boot0002* Windows Boot Manager
Boot0003* USB CD/DVD ROM Drive (UEFI) (Single Flash Reader)
Boot2001* EFI USB Device
Boot3002* Internal Hard Disk or Solid State Disk
Hm, that did not work as expected. Despite I left out the windows thing, it is still listed. But let’s continue.
I tried then reboots, and the Windows Boot Manager still took over control.
So next, I remove totally the useless Windows Boot Manager.
efibootmgr -b 2 -B
Output UEFI boot partition:
os-prober
For my notebook, the partition printed out is /dev/nvme0n1p1.
Finally, remove the Microsoft/Windows directory (check for name, can vary) on that partition:
mount /dev/nvme0n1p1 /mnt
cd /mnt/EFI
rm -rf Microsoft
umount /mnt
And tada, finally it is gone.
Install UEFI key for VirtualBox
This is another ugly story.
First, add user to vboxusers via Yast.
Then add kernel modules
# zypper install virtualbox-host-source kernel-devel kernel-default-devel
# vboxconfig
Building kernel modules...
Kernel modules built correctly. They will now be installed.
insmod /lib/modules/5.14.21-150400.24.46-default/weak-updates/extra/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxnetflt': Key was rejected by service
insmod /lib/modules/5.14.21-150400.24.46-default/weak-updates/extra/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxnetadp': Key was rejected by service
Kernel modules are installed and loaded.
This is an old and annoying bug in VirtualBox + OpenSuse.
The modules built on the fly by the command vboxconfig are signed with
a key which is not known by UEFI. They are signed with which key?
# modinfo vboxdrv
filename: /lib/modules/5.14.21-150400.24.46-default/weak-updates/extra/vboxdrv.ko
version: 7.0.6_SUSE r155176 (0x00330004)
license: GPL
description: Oracle VM VirtualBox Support Driver
author: Oracle and/or its affiliates
suserelease: SLE15-SP4
srcversion: D05A1BCB972CB01E9C9711E
depends:
retpoline: Y
name: vboxdrv
vermagic: 5.14.21-150400.24.41-default SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: openSUSE Secure Boot CA
sig_key: FA:BE:D8:BF:40:9A:5E:65
sig_hashalgo: sha256
signature: 08:02:CF:DA:23:B0:87:CF:0D:52:08:16:85:8F:0A:07:31:DF:72:1A:
2E:6A:06:43:28:72:2D:6B:D0:34:09:AB:F7:0C:36:C2:80:DB:2E:60:
...
99:08:06:5F:1F:70:23:2E:DC:E7:8F:A9:A1:47:EE:F0
parm: force_async_tsc:force the asynchronous TSC mode (int)
Check line with signer. So these modules are signed with signer openSUSE Secure Boot CA.
What keys are known to UEFI on my notebook?
# mokutil -l
[key 1]
SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
Validity
Not Before: Apr 18 14:33:41 2013 GMT
Not After : Mar 14 14:33:41 2035 GMT
Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:cd:fd:ab:d7:2a:84:f8:81:c3:36:35:50:35:2c:
...
13:31:b8:21:de:ac:30:9d:99:e1:6b:44:61:0c:43:
3d:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
X509v3 Authority Key Identifier:
keyid:EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
DirName:/CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
serial:01
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
12:be:2c:85:85:5a:94:59:cd:49:51:08:17:c1:d9:63:27:29:
...
19:70:dd:1e:e6:21:f2:a3:31:19:1e:c3:b4:ae:f7:35:a7:a1:
b4:61:6b:4e
Check line with Issuer. So there is only a single key known to UEFI, and it is issued by
CN=SUSE Linux Enterprise Secure Boot CA, C=DE,.... This key is obviously
different from the one that was used to sign the VirtualBox modules.
This means that these modules are rejected by UEFI and will not be loaded.
Solution: We have to add the key that was used to sign the modules to the list of modules known by UEFI.
UEFI keeps all known keys in a store (also called keyring).
I checked the key files that I have on my system, located in /etc/uefi/certs.
With mokutils -t <key> it can be checked if a key from a key file is
known by UEFI. I did this with all keys that are located in the directory.
mokutil -t /etc/uefi/certs/1F673297-kmp.crt --> unknown
mokutil -t /etc/uefi/certs/40905999.crt --> known
mokutil -t /etc/uefi/certs/BCA4E38E-shim.crt --> known
It was found that the key 1F673297-kmp.crt was not yet known to UEFI.
So I loaded this into UEFI key store (hoping that this was the missing key). This is done in two steps. First place the order to add the key:
mokutil -i /etc/uefi/certs/1F673297-kmp.crt
Then reboot. During reboot, UEFI will see the order to add the key and will allow the user to accept or reject the key.
After accepting the key, boot continues. You can check after booting if the key now is contained in UEFIs list of keys:
# mokutil -l|grep Issuer
Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
Looks good.
After this, VirtualBox command can be executed without the issues.
Add apps to latte-dock
App desktop file location: .local/share/applications/
All these occur in launchers and can be added to latte.
Restart broken plasma desktop
On my new AMD Ryzen CPU notebook with 16 cores, frequently the plasma desktop is suddenly terminating. This is usually after switching external monitor to another machine and then coming back to my machine. Happened at leat one time per day. With same OpenSuse version and another notebook (HP Probook with Intel i7 CPU) I never experienced this. Very ugly.
kstart5 plasmashell
See: https://askubuntu.com/questions/481329/can-i-restart-the-kde-plasma-desktop-without-logging-out
Using vnc server and vncviewer
This issue is also frequently discussed in internet groups, but I did not found a short and simple way to solve it. Here it is.
Start vnc server:
vncserver
This is a shell script and on first use, it will prompt for a password.
Enter the password. This is the password required to access
the server from a client. The vnc server then will be started.
The password is then stored in ~/.vnc/passwd. There is also a config file
~/.vnc/config which can be ignored for now.
Install a vnc viewer. On OpenSuse, the package is called TigerVnc. After installation, start it with:
vncviewer --SecurityTypes=VncAuth <hostname>:<display_number>
For a host called k8 and display number 0, you would enter vncviewer k8:0.
It will prompt for the password you have defined above.
If you do not specify the security type as described above, you usually get an error messsage like “no matching security types”.