Tag Archives: Wayland

Opensuse Leap 15.4 – Online Upgrade from Leap 15.3 on an Encrypted Laptop

Posted on by

After my retirement I was overwhelmed by a lot of typical German bureaucracy. But last weekend I used some time to start the long overdue upgrade of my old laptop from Opensuse Leap 15.3 to Leap 15.4. (The support for Leap 15.3 ended the at the end of 2022.)

I am always a bit afraid of upgrading my old laptop. It has a somewhat complicated configuration:

Its LVM volumes are fully encrypted with LUKS 2. It is an Optimus-System – and in the past it was not always easy to switch from the integrated Intel graphics card to the dedicated Nvidia card. Instead of Bumblebee I have used Opensuse’s Prime-Select with Leap 15.3. I use KDE as my graphical desktop environment. On Leap 15.3 I did not yet apply Wayland – but I intend to switch to Wayland with Leap 15.4. For some of my activities I also use Blender with full OpenGL support in form of a Flatpack installation. Furthermore, the laptop is used for both Machine learning, i.e. Python development, as well Web-development based on LAMP. So, it hosts a variety of services you normally find on servers. In addition we have KVM and VMware WS Pro installations. So, there are a lot of things which can go wrong. The Nvidia card is also an old one – a GT 645M which cannot be run with the latest generation of Nvidia drivers.

The good message is: The upgrade from leap 15.3 to 15.4 went very smoothly. At least regarding the things I was interested in. Below I describe the steps I have taken to upgrade. With some modifications you should be able to adapt it to your situation.

Backup of the encrypted LVM volume mounted on “/”

On my desktop PCs with Opensuse-installations, which I use for daily work, I follow a two-fold “backup”-policy ahead of upgrades: I copy my root-volume/partition to another LVM-volume or partition, and make it bootable in parallel to the existing installation. Reason: I want to be able to quickly switch to my present installation in case of trouble. As I have all of my personal and project data on separate LVM volumes with dedicated backups, the root-volume is the only one which I really must take care of. Therefore, I also copy it to a backup file on an external disk. For all data volumes I have a separate backup routine.

On my laptop I am a bit more relaxed: I just copy the volume mounted on “/” to an external disk. I have no second bootable installation on some other encrypted volume on the laptop. This means that I must boot a Live system or a Rescue system to make a backup of the unmounted “/”-volume.

For my purposes the Leap 15.3 “Rescue System”, which you can find on an DVD-ISO-image for the installation of Leap 15.3, was sufficient. You get the ISO image for such a DVD from opensuse.org and can burn it onto a DVD. The steps afterward were as follows:

  1. Boot your Leap 15.3 system. Check, on which partition or LVM volume your (encrypted) root-filesystem resides. Use e.g. YaST’s partitioner or gparted for this purpose. Shut down.
  2. Insert the DVD, select a boot menu, select the DVD, start from it, select “More …” in the GRUB-like menu, then select the DVD with the “Rescue System” and boot it.
  3. Login as root (no password required). Check that a tmpfs is mounted on / – and not some real partition.
    Note: The root-filesystem of our Leap-installation is NOT mounted on “/” of the rescue system. When I speak of the “root-filesystem” below I always refer to the filesystem containing the operative system of our current Leap 15.3 installation and not the root-fs of the rescue system.
  4. Check with command blkid what the device names of all accessible partitions and LVM volumes are. You should see encrypted and other volumes/partitions of your laptop disks/SSDs there.
  5. Plugin an external backup USB-disk. blkid should now also show the partitions on this disk, too.
  6. Mount the target filesystem of the external disk, where you want to place your backup, onto “/mnt” in your booted rescue system. Check the available space. In my case (with sdc being the external disk) : 
    tty1:rescue:~ # mount /dev/sdc2 /mnt
tty1:rescue:~ # df -h 
..
/dev/sdc2     825G   78G   706G     10%   /mnt 
...
  7. Locate your Leap 15.3 root-filesystem. In my case the root-filesystem of the laptop is an LUKS2-encrypted LVM available as “/dev/mapper/vgb-lvb2”. Note: You must know in advance, i.e. from your Leap 15.3 setup, where your root-filesystem resides.
  8. We now use the command “dd” to copy the root-filesystem onto a restorable image file. In my case: 
    dd status=progress if=/dev/mapper/vgb-lvb2 of=/mnt/root_lap.img

After the backup of the (encrypted) root-fs of our Leap 15.3 installation we shut down the rescue system, remove the DVD and boot Leap 15.3 again.

Check your RPM repositories – refresh and update

On the rebooted Leap 15.3 we check what we have of active repositories. In my case these were quite many:

(Ignore the double “mozilla” entry.)

Recommendation: You should make a similar screenshot and save it somewhere outside your laptop to later be able to restore all of the different repositories for Leap 15.4.

However, the most important repositories required to perform the upgrade are three update repositories:

  • One with renewed RPMs for the OSS,
  • one for Backports (backportet RPMs, e.g. security RPMS backportet from newer kernel or glibc related versions than the presently available versions on Opensuse Leap/SLES)
  • and one for renewed RPMs for the SLES version corresponding to the current Leap.

Update-repositories contain the latest RPMs of an Opensuse distribution. In our upgrade process we still deal with relevant update repositories for Leap 15.3. But we are soon going to exchange them with their Leap 15.4 counterparts.

Look out for the URLs of the current update repositories :

 * https://download.opensuse.org/update/leap/15.3/oss/
 * https://download.opensuse.org/<br>update/leap/15.3/backports/
 * https://download.opensuse.org/<br>update/leap/15.3/sle/ repo-sle-update

Leap 15.3 and 15.4 RPMs are binary compatible to those for the related SLES versions. In my case I had switched most of my Leap 15.3 RPMs to those of the update repo of SLES already a long time ago. If you have not done this yet you should do so now with the help of YaST.

I also directly deleted the repository for games as I regard it unimportant during an Upgrade.

Now, we refresh the lists of available RPMs and update to the latest versions. You can use the graphical YaST2 for this purpose or the command line:

mytuxlap:~ # zypper refresh

Then we perform an update of our Leap 15.3 RPMs to the latest available versions:

mytuxlap:~ # zypper update

In my case some of my Leap 15.3 repositories (for games, graphics, xfce and for snappy) were no longer available and could not be refreshed. I just had waited too long with my upgrade. But this resulted in no major problems during the upgrade.

After the update reboot and verify that your Leap 15.3 system still works.

Change repository URLs to contain the ${releasever} instead of an explicit version number

We change the URLs of our repositories now to contain ${releasever} instead of an explicit “15.3” in the URLs. It is easy to do this on the command line:

mytuxlap:~ # sed -i 's/15.3/${releasever}/g' /etc/zypp/repos.d/*.repo
mytuxlap:~ # sed -i 's/$releasever/${releasever}/g' /etc/zypp/repos.d/*.repo

The second command is just for being on the save side of the shell interpreter. I had previously already changed some of the repo URLs to include $releasever, but I want everything to consistently use ${releasever}.

Refresh for Leap 15.4 repository content – and eliminate some repositories

Next we start switching to the repositories for Leap 15.4. The first step is a refresh on the command line, but now for the Leap 15.4 repos. We can do this with the help of the variable ${releasever} in the following form:

mytuxlap:~ # zypper --releasever=15.4 refresh

Note that this does not yet change our repositories themselves, yet, but just the local content information. It gets replaced by lists about the contents of the Leap 15.4 repositories.

In my case this refresh process lead to errors. The reason was that some of the repositories which I used on Leap 15.3 had got a different path structure of the respective web resource below “download.opensuse.org/” for Leap 15.4. You have to ask the Opensuse people why they changed this. 

mytuxlap:~ # zypper --releasever=15.4 refresh
Warning: Enforced setting: $releasever=15.4
Retrieving repository 'nVidia Graphics Drivers' metadata ...........................................[done]
Building repository 'nVidia Graphics Drivers' cache ................................................[done]
Retrieving repository 'Packman Repository' metadata ................................................[done]
Building repository 'Packman Repository' cache .....................................................[done]
Retrieving repository 'Update 15.4' metadata .......................................................[done]
Building repository 'Update 15.4' cache..... .......................................................[done]
Retrieving repository 'graphics' metadata .........................................................[error]
Repository 'graphics' is invalid.
[openSUSE_Leap_${releasever}_1|https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.4/] Valid metadata not found at specified URL
History:
 - [openSUSE_Leap_${releasever}_1|https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.4/] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'graphics' because of the above error.
Retrieving repository 'mozilla' metadata ...........................................................[done]
Building repository 'mozilla' cache ................................................................[done]
Retrieving repository 'XFCE' metadata .............................................................[error]
Repository 'XFCE' is invalid.
[openSUSE_Leap_${releasever}_3|https://download.opensuse.org/repositories/X11:/xfce/openSUSE_Leap_15.4/] Valid metadata not found at specified URL
History:
 - [openSUSE_Leap_${releasever}_3|https://download.opensuse.org/repositories/X11:/xfce/openSUSE_Leap_15.4/] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'XFCE' because of the above error.
Retrieving repository 'Libdvdcss Repository' metadata ..............................................[done]
Building repository 'Libdvdcss Repository' cache ...................................................[done]
Retrieving repository 'Update repository of openSUSE Backports' metadata ...........................[done]
Building repository 'Update repository of openSUSE Backports' cache ................................[done]
Retrieving repository 'Non-OSS Repository' metadata ................................................[done]
Building repository 'Non-OSS Repository' cache .....................................................[done]
Retrieving repository 'openSUSE-Leap-15.4-Oss' metadata ............................................[done]
Building repository 'openSUSE-Leap-15.4-Oss' cache .................................................[done]
Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15' metadata ......[done]
Building repository 'Update repository with updates from SUSE Linux Enterprise 15' cache ...........[done]
Retrieving repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' metadata ...........[done]
Building repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' cache ................[done]
Retrieving repository 'snappy' metadata ............................................................[done]
Building repository 'snappy' cache .................................................................[done]
Some of the repositories have not been refreshed because of an error.

Then I changed again to the repository administration of YaST and simply deleted the problematic repos. We will care for their new URL later.

Note: The fact that we may have RPMs from missing repos during the upgrade is later on compensated by allowing for a “vendor change” – which means a repository change. See below.

After having eliminated problematic repos we get a successful refresh for the contents of remaining 15.4 repositories on the command line:

mytuxlap:~ # zypper --releasever=15.4 refresh
Warning: Enforced setting: $releasever=15.4
Repository 'nVidia Graphics Drivers' is up to date.                                     
Repository 'Packman Repository' is up to date.                                          
Repository 'mozilla' is up to date.                                                     
Repository 'Libdvdcss Repository' is up to date.                                        
Repository 'Update repository of openSUSE Backports' is up to date.                     
Repository 'Non-OSS Repository' is up to date.                                          
Repository 'openSUSE-Leap-15.4-Oss' is up to date.                                      
Repository 'Update repository with updates from SUSE Linux Enterprise 15' is up to date.
Repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' is up to date.     
Repository 'snappy' is up to date.                                                      
All repositories have been refreshed.

Download of the RPMs without applying them, yet

The next step is to download the RPMs from the Leap 15.4 repos and save them in a cache for the later upgrade process. On a TTY or a root terminal window 

mytuxlap:~ #  zypper --releasever=15.4 dup --download-only --allow-vendor-change

The option “–download-only” avoids the installation of the new 15.4 RPMs. Also note the option “–allow-vendor-change”: If a RPM cannot be replaced a substitute from other major repositories will be used – if one is found.

Agree to the RPM setup displayed and the license conditions. Some 5 to 10 minutes later, after having downloaded everything, we must deactivate the graphical desktop.

Perform the Upgrade on an ASCII terminal (TTY)

On a system with both an integrated Intel card and a dedicated Nvidia card you may first want to decide which card driver you want to be loaded during the upgrade. You may use the Prime-Select Applet of Opensuse to switch to Intel on your desktop. Then logout and login again and check whether the Nvidia driver is no longer active.

Personally, I just kept the Nvidia card and the respective driver running. The resulting small problems were easy to overcome; see below. 

mytuxlap:~ # lsmod | grep nvidia
nvidia_drm             69632  5
nvidia_modeset       1204224  6 nvidia_drm
nvidia              35512320  281 nvidia_modeset
drm_kms_helper        303104  2 nvidia_drm,i915
drm                   634880  10 drm_kms_helper,nvidia,nvidia_drm,i915,ttm
mytuxlap:~ #

Important: Logout now of the graphical desktop to perform the Upgrade.

Move to an ASCII terminal (e.g. via Ctrl-Alt F1). There login as root. Type in “init 3” to stop your running X- or Wayland server. And then start the real upgrade and the respective rpm installation via “zypper –no-refresh –releasever=15.4 dup –allow-vendor-change” :

mytuxlap:~ # init 3 
mytuxlap:~ # zypper --no-refresh --releasever=15.4 dup --allow-vendor-change

You must again confirm the RPM configuration and the license conditions. Depending on your previous configuration several thousands of packages will then be installed the next 10 minutes or so from the preloaded and cached RPMs.

After all required RPMs have been installed just reboot by typing “init 6” on the command line.

My Leap 15.4 situation after reboot

In may case the systems behavior after reboot was a bit strange.

The good news is:

I experienced no problems with LUKS 2, grub2, initramfs and the second phase of the startup during which all of my other LUKS2-encrypted LVM volumes were decrypted, checked and mounted.

Off topic: Leap uses initramfs, but stores it at /boot/initrd.

The whole startup process worked like before: I get asked for the LUKS2 decryption key directly after starting the boot process, then the graphical grub2 menu comes up and I can start the primary phase of the boot process based on initramfs. In my installation, due to security precautions, I was asked to provide the decryption key once again before the second boot phase on the real root-filesystem started. (Off topic: There are configuration tricks to circumvent the 2nd request for the LuKS2 key, but my personal opinion is that the asking a second time enhances security a bit. I cannot go into the related details of a LUKS 2 configuration here.)

The bad news is:
The behavior of the Optimus environment was not consistent. Although the Nvidia RPMs had been shifted to those from the Nvidia community repository for Leap 15.4 after the reboot the Intel i915 was loaded – and I did not manage to activate the Nvidia driver. Also bbswitch interfered with my trials and shut down the Nvidia card:

The warm reboot directly after the upgrade seemed to work without major error messages (with the exception of an expected VMware related error; see below). The startup process eventually led to graphical login screen of sddm.
After login the applet for Prime-Select told me that Nvidia was active.

However, after shutting the laptop down completely and starting it via a cold boot I saw that the laptop’s LED signalling the activation of Nvidia was off (more precise showing a blue instead a red color). The Intel driver i915 was loaded with the start of the sddm login screen. Afterward the X11-KDE/Plasma combination actually worked perfectly with it. As did the combination Wayland and KDE Plasma; see below.

But at least for work with Blender I do need an active Nvidia card on the desktop. So, how to get it running?

Optimus – and a small problem with the Nvidia card

When I turned to a TTY and issued “init 3” I, actually, could activate the NVidia card via

mytuxlap:~ # tee /proc/acpi/bbswitch <<< ON

And I also could load the Nvidia driver by

mytuxlap:~ # modprobe nvidia

In addition 

mytuxlap:~ # prime-select nvidia

seemed to be accepted by the system.

However, when I afterward wanted to start the graphical desktop again via “init 5” I experienced that the Nvidia card was directly deactivated and that the Nvidia driver, therefore, could not work or be reloaded.

What a stupid situation! Obviously, the configuration of bbswitch had not been aligned correctly with prime-select and Nvidia during Upgrade.

Solution
In the end the solution was simple: I turned to a TTY, issued “init 3”, activated the Nvidia card, loaded the present driver and used the ASCII version of YaST (not graphical yast2) to reinstall (= update unconditionally) the Nvidia drivers from the Nvidia repository

I had to pick the G05-drivers as my graphics card is rather old. Note that the driver version 470 is also relatively old and has been reported to have some problems with the display manager Wayland.

After reboot everything then already worked as expected:
The Nvidia card was activated from the start and used for the graphical desktop afterwards. And I could use the Prime-Select Applet to switch to the Intel Driver with a subsequent logout from the KDE desktop and then a re-login. With Intel the Nvidia card got deactivated – which is very reasonable as it reduces the power consumption and heat generation of the laptop.

You may also check if things are already OK after a re-installation of the Nvidia drivers. The probably important thing is that during the reinstallation mkinitrd is started in the background and dracut is forced to re-configure the initramfs – this time with a loaded Nvidia driver.

If things still do not work in your case: Check that you have blacklisted the Nouveau driver in file “/etc/modprobe.d/50-blacklist.conf” and/or “/etc/modprobe.d/nvidia-default.conf” with entries

blacklist nouveau
options nouveau modeset=0

Then stop the graphical target again: Go to a terminal (Ctrl-Alt-F1), use “init 3” and try 

mytuxlap:~ # init 3 
mytuxlap:~ # tee /proc/acpi/bbswitch <<< ON
mytuxlap:~ # modprobe nvidia

This should work. Then

mytuxlap:~ # mkinitrd

Then reboot. On the graphical desktop (probably still using the Intel driver) open a root terminal window. Try

  
mytuxlap:~ # prime-select nvidia

Log out from the graphical desktop, watch the laptop LED indicating the activation of the Nvidia card (should now show that Nvidia is on), log in and check that the Nvidia driver was loaded:

mytuxlap:~ # lsmod | grep video

This should give you something like:

mytuxlap:~ # lsmod | grep nvidia
nvidia_drm             69632  7
nvidia_modeset       1204224  16 nvidia_drm
nvidia_uvm           1138688  0
nvidia              35512320  980 nvidia_uvm,nvidia_modeset
drm_kms_helper        303104  2 nvidia_drm,i915
drm                   634880  12 drm_kms_helper,nvidia,nvidia_drm,i915,ttm

Then test the reversion to the Intel driver via Opensuse’s prime-select applet. Should work now.

No cube animation for switching virtual desktops on KDE any more!

I had a brief look at other things on my new Leap 15.4 installation. Regarding KDE on Xorg the only thing I could complain about on Leap 15.4 was that the rotating cube animation for switching between virtual desktops was gone. This is due to decisions of the KDE people. So, Opensuse is NOT to blame for it. Personally, I think the loss of the animation is a pity, but it does not hinder any productivity, either. So, no big thing …

Wayland with KDE 5.24

A switch off the display server from Xorg to Wayland is a major step. I had been reluctant to use Wayland with Leap 15.2 and 15.3. Kernel, KDE and the Nvidia driver – all of their components must support Wayland. Unfortunately, Nvidia has for years been a major hinder in the support process – in contrast to Intel or AMD. So, I was a bit skeptical with Wayland, KDE/Plasma and Nvidia’s 470-driver on my old graphics card.

Positive results: KDE 5 started well. The startup of the desktop took longer time than with Xorg but completed successfully. Afterwards: No flickering of KDE, no problems with switching between virtual desktops or 3D desktop animations. Glxspheres worked. No problems with new windows of browsers like Firefox or Chromium – as were previously reported by others.

Best of all: My flatpack installation of Blender 3.3 did work very well.

Negative results: Nvidia-settings 470 did not work. Also, 3D-animation effects like wobbly windows appeared to have a slightly better performance on Xorg. After a session break (and the display of a protection screen with the option to relogin) a return to the KDE session lead to a strong white-flickering of the background. But this could be stopped by a mouse-click on the flickering background.

All in all: Even on my relatively old laptop I can productively use Wayland with Opensuse Leap 15.4 and KDE/Plasma 5.24 and Nvidia driver 470.

Leap 15.4 repositories with different locations than for 15.3

In general we can find available repositories at “https://download.opensuse.org”. The graphics repository has found a new location at 

https://download.opensuse.org/repositories/graphics/15.4/,

the XFCE at 

https://download.opensuse.org/repositories/X11:/xfce/15.4/.

Use Yast to add these repositories back to your list of active Leap 15.4 repos.

Still no actual Blender version on Leap 15.4

Note: Blender in a version above 2.82 is still not available for Leap 15.4. Which is a major shame. The glibc version is just too old for Blender 3.x. The only way out of this dilemma is a Flatpack or Snap based installation of Blender 3.4.
Such installations work, however, very well on Leap 15.4 – both with Xorg and Wayland.

Multimedia: Change system packages to RPMs of the packman repository

A broad range of multimedia tools and codecs require the packman repositories. What I typically do is to add a mirror with the packman repository, e.g. 

https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_${releasever}/

to the list of repositories, use YaST2 for the display of the contents of this repository and then click on the link “Switch system packages to the versions in this repository (Packman repository)”.

I tested some typical multimedia applications I use: Pulseaudio, PA equalizer, Clementine, VLC and TV channels on browsers. No problems.

What about Python?

My last development work on a desktop machine was done with Python 3.9, Jupyter notebooks and Eclipse. Leap 15.4 offers Python 3.6 as the standard. However, you can in parallel install either Python 3.9 OR Python 3.10. the OR is unfortunately exclusive. (The current Python version is 3.11).

I think I can live for some time with Python 3.10. So, I tested an installation of a virtual Python environment on Leap 15.4. The key to do so is to move to a directory where you want to implement your virtual environment – and install the relevant interpreter plus related basic directories. The following commands show an example: 

myself@mytuxlap:~> mkdir /projekte/GIT/ml_5
myself@mytuxlap:~> cd /projekte/GIT/
myself@mytuxlap:/projekte/GIT> virtualenv -p /usr/bin/python3.10 ml_5 
myself@mytuxlap:/projekte/GIT> cd ml_5
myself@mytuxlap:/projekte/GIT/ml_5> source bin/activate
(ml_5) myself@mytuxlap:/projekte/GIT/ml_5> pip install --upgrade pip
Collecting pip
  Using cached pip-23.0.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 20.2
    Uninstalling pip-20.2:
      Successfully uninstalled pip-20.2
Successfully installed pip-23.0.1
(ml_5)  myself@mytuxlap:/projekte/GIT/ml_5> pip install jupyter      
Collecting jupyter
  Using cached jupyter-1.0.0-py2.py3-none-any.whl (2.7 kB)
...
...
(ml_5) myself@mytuxlap:/projekte/GIT/ml_5> jupyter-notebook 
...

This all works – but there are some (expected) errors regarding the jupyter_nbextensions_configurator. This is all well known – and also what has to be done to configure the jupyter_nbextensions correctly. This is no matter of leap 15.4.
Anyway, a Jupyter notebook will start in your default browser and you can start working with Python 3.10. I systematically added the needed libs and modules afterward with the help of pip. So, no majro problem with Python 3.10 on Leap 15.4!

What about PHP?

Well, Leap 15.4 offers an installation of either PHP7 or PHP8.0. I picked PHP8. But how does PHP 8 work together with a standard Apache2 installation on Leap 15.4?

Answer: It depends!

From the Apache point of view we would like to distribute the web server’s load on multiple Apache processes with a minimum consumption of RAM. Therefore, we would like to run Apache with an event based MPM module or just with the standard MPM-module. The problem is that this does not work with PHP. This problem already existed for lower PHP-versions than PHP 8.

You run into an error message like:

Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP.

There are two solutions to this problem:

  • Switch to a prefork configuration of Apache 2.4 – and ignore the resulting RAM consumption
  • Use FastCGI and php8-fpm.

You also have to decide which method you want to use for changing the Apache2 configuration on Leap 15.4. You can remove RPMs or use a2enmod, a2dismod and maybe a2config, respectively. Relevant commands in our case would be “a2dismod mpm_worker”, a2dismod mpm_event” and a2enmod mpm_prefork”.

The easiest way, however, is to remove the RPMs “apache2-event” and/or “apache2-worker”, depending on what kind of configuration you have installed. I have no time to discuss the specific differences of these types of Multi-process setups of Apache2 here. To be able to activate prefork the RPM apache2-prefork must be installed. A reasonable RPM selection for a prefork variant would then look like this:

With this RPM selection you can just start Apache2 with the following modules successively: 

mytuxlap:~ # rcapache2 restart
mytuxlap:~ # a2enmod rewrite 
mytuxlap:~ # a2enmod -l
actions alias auth_basic authn_core authn_file authz_host authz_groupfile authz_core authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl socache_shmcb userdir reqtimeout php8 version mpm_prefork rewrite
mytuxlap:~ #

I.e.: For the simple prefork solution we can either try to disable the modules mpm_worker and/or mpm_event and activate “mpm_prefork” OR remove/install related RPMs.

But there is also another way to get PHP8 running – which is based on a FastCGI configuration of Apache2 together with the installation of a service for php8, namely php8-fpm. Personally, I have not yet tried a fast-cgi / php8-fpm combination on Leap 15.4. But I intend to describe the setup soon in this blog. In the meantime, please, check the information at the following links. It is given for other operative systems, but an adaption is straightforward.

Note: php-fpm is a service which must be started on your system via systemd’s command “systemctl”.

Digital ocean on PHP-fpm and Apache2 for Ubuntu 18
Digital Ocean on PHP and BSD
Digital ocean on PHP-fpm and Apache2 for Ubuntu 20

VMware and KVM

KVM works on leap 15.4 wwithout problems. I could directly start an existing qemu-virtualized Debian installation.

VMware WS also works on Leap 15.4. But you must have a version > WS 16.2.3 available. I updated to WS 16.2.5 by installing the bundle “VMware-Workstation-Full-16.2.5-20904516.x86_64.bundle”. Afterward I could start both VMware-virtualized Windows 10 and Win 7 installations on a Leap 15.4 KDE desktop without any problems.

Conclusion

The Upgrade from Opensuse Leap 15.3 to Leap 15.4 (with a KDE desktop) works without major problems even on older laptops with old Nvidia mobile graphics cards. Its a bit irritating that some Leap repositories got a new location with Leap 15.4 – but this can be fixed after the Upgrade.

A big positive surprise was that KDE 5.24 worked with Wayland even on my old Nvidia GT 645M card. A current Blender version MUST, unfortunately, be installed via Flatpack. Python 3.10 and PHP 8.0 are supported. KVM and VMware WS 16.2.5 pose no problems on Leap 15.4.

Happy working with Leap 15.4!

Links

Wayland vs. Xorg
https://linuxiac.com/ xorg-x11-wayland-linux-display-servers-and-protocols-explained/

Apache2 and PHP8
https://bbs.archlinux.org/ viewtopic.php?id=178124

 

Ceterum censeo: The worst fascist, war criminal and killer living today is the Putler. He must be isolated at all levels, be denazified and sooner than later be imprisoned. A president who orders the systematic destruction of civilian infrastructure must be fought and defeated because he is a permanent danger to basic principles of humanity. He must be brought to justice in front of an international court. Long live a free and democratic Ukraine!

 

Upgrade workstation from Opensuse Leap 15.1 to Leap 15.2

Posted on by

Two weeks ago I upgraded my main Linux-Workstation from Leap 15.1 to Leap 15.2. Some first impressions:

  • Leap 15.2 with KDE/X11 works relatively well. Some minor setting-options for the Plasma desktop have changed.
  • KDE/Wayland with Nvidia cards does not work – unusable for production.
  • No problems with QEMU based KVM- and LXC-container virtualization – my old Debian and Kali guest systems worked as expected on the Leap 15.2-host. No problems with multi-screen configurations of the guests with remote-viewer either.
  • Unexpected high power consumption of the Nvidia card – it has increased by about 5% to 8%. I am not sure whether this is a KDE or a driver problem.
  • The usual suspects for problems during the upgrade are the Nvidia drivers, Pulseaudio, VMware and this time – to my big surprise – CUPS.
  • You may have to change/reset some KDE config and rc-files in your home-directory – especially for the plasma desktop itself.
  • Chromium showed some glitches.

I shortly describe the upgrade process and some obstacles I had to overcome.

Basic upgrade process

I always prepare for a quick restoration of my running system configuration (here: Leap 15.1). Ahead of any upgrade activity, I therefore create a backup of my Leap 15.1 “/”-filesystem on an external drive and in addition create another copy in a target partition on one of my bootable disks. I use the “dd“-command for both purposes. As all productive application and development data as mails, project documents, PHP- and Python modules are on independent partitions or on network locations anyway, the risk of running into major problems afterwards is relatively small. In addition I comment certain critical entries in the “/etc/fstab” out.
In case of a major disaster a recovery can be achieved very quickly by just re-copying the copy of the Leap 15.1 partition back to its original place.

Regarding the backup of the “/”-filesystem to an external disk you have the choice between creating a copy of a partition and creating a (zipped) file. See e.g.:
https://www.poftut.com/linux-dd-command-backup-examples/
https://linoxide.com/linux-command/linux-dd-command-create-1gb-file/
I just made simple partition copies. Regarding the blocksize “bs” option of “dd” I am very generous with SSDs; I use a size like bs=1M or bs=4M to get a reasonable performance. When copying around 100 GB you probably do not want to wait for an hour :-). E.g.:

dd if=/dev/sdg1 of=/dev/sdh5 bs=4M status=progress

Warning 1:

If you copy your partition with “/”-filesystem into another partition, then the target partition must at least have the size of the original one. Really take care of this point! I always try to achieve the exact same size with a partition tool (gparted or YaST partitioner).

Warning 2:

Do not forget to change the UUID of the partition’s copy if the target partition resides on an internal disk; you should never have two filesystems with the same UUID on a system! But write down the original UUID at a safe place. Use “uuidgen
” and the “tune2fs -U” commands to change the copied filesystem’s UUID, afterwards.

See: how-to-change-filesystem-uuid-2-same-uuid

And: In case of an emergency restoration, i.e. after having copied the backup filesystem into its old position, you, of course, have to change the UUID back to the old one.

Why are these UUID-precautions required?
Because of your boot-loader – probably Grub2. Depending on its configuration (and some other system settings) it will probably have created entries in the “/boot/grub2/grub.cfg” which refer to the UUIDs of the bootable partitions. And if such a UUID-reference cannot be resolved in a unique way you may in the best case boot a system you did not want to boot, but you may also experience worse conflicts. Now, you may ask:

What is the copy on the same or another internal hard disk good for anyway?
I create the copy on my main SSD (or another internal disk) not only for restoration purposes, but also for the purpose of transforming it into a fully bootable filesystem at its new position later on – i.e. after the upgrade. I shall return this point in an extra section below.

Upgrade process

After the backup procedures I followed the guideline of the Brasilian Linux Kamarada for the upgrade; see
https://kamarada.github.io/en/2020/09/01/linux-kamarada-and-opensuse-leap-how-to-upgrade-from-151-to-152

Their way of upgrading Opnesuse systems is straight-forward and well-tested. I also liked their recent inclusion of the “releasever“-variable …

I tend to use multiple repositories besides the standard upgrade repository of Opensuse. Therefore, I had to delete quite an amount of repositories following the Kamarada recipe. If you are in the same position, you should make a screenshot of the repository-configuration in YaST to be able to reconfigure them after the upgrade. During the upgrade zypper may recognize many packages for which it has to change the repository. It is a bit of an ordeal to answer to all of the related questions, but I recommend to follow the questions with focused concentration: The order of offered alternatives may change!

Hint: Take care of sufficient filesystem-space! The download of new packages requires extra space during the upgrade period – and usually also the total size of used disk space after an upgrade typically tends to grow somewhat. Therefore: Have at least 20GB available on your “/”-filesystem. (LVM is your friend – if you use(d) it …).

After the upgrade you have to reboot (init 6). If your graphics card is from Nvidia you probably will find yourself on some console terminal and not at a desktop-manager-login (e.g. sddm or gdm3) at the end of the boot process. We must install the (new) Nvidia drivers afterwards.

Nvidia re-setup

There are at least two ways of installing Nvidia-drivers on an Opensuse-system: 1) Directly, i.e. by a manual installation with the help of of the downloaded driver installation scripts. 2) With the help of YaST and the Nvidia community repository. I have used the latter option during the last 2 years. Either way you probably prohibited loading the Opensource Nouveau driver already at some point in the past – e.g. by blacklisting the related kernel module in some of the files in “/etc/modprobe.d”. If not – it is time to do so now.

When you rebooted after the Leap 15.2 upgrade the old Nvidia modules did not work as they were not compiled for the new kernel which was installed during the upgrade. So, from the console login, which you hopefully have reached, you need to invoke YaST in ASCII-mode, activate the
Nvidia community repository and reinstall the proprietary Nvidia drivers from there. In my case the packages

nvidia-computeG05, nvidia-gfxG05-kmp-default, nvidia-glG05, x11-video-nvidiaG05

A compilation is done automatically during this update.
Hint: I also suggest to issue “mkinitrd” immediately after the driver installation to be on the safe side regarding the “initramfs”-phase of the boot-process.
This worked pretty well in may case. After a reboot I got to my SDDM-login screen afterwards. My standard X11-based graphical KDE Plasma desktop started smoothly afterwards. I also tested the functionality of my Cuda installation for Keras and Tensorflow2 – worked perfectly.

Increased idle power consumption of the graphics card on a running KDE plasma desktop (Version 5.18)
A unwelcome surprise regarding Nvidia was the following: When watching the power consumption of my graphics card with

watch -n0.1 nvidia-smi

I saw a rise in the average consumption.
An average value of the GPU load (with “Force Composition Pipeline” activated on all my 3 screens) now had a value of 15%; on my old Leap 15.1 it was below 10%. All with having set the Powermizer mode to “Adaptive” (via (nvidia-settings). I fiddled a bit around with some Nvidia settings – but found no real solution, yet. When I changed a desktop theme (with the help of “systemsettings5”) I observed a drop of power consumption to 11% – but after some movement of windows across my 3 screens it settles again at 15% – quite independent of style and desktop settings. At least with an OpenGL-compositor activated (systemsettings5 >> “screen … >> compositor”. Choosing “Xrender” leads to a drop of GPU-consumption to 9%.

What brought me down a bit to 12% with an activated OpenGL-compositor (OpenGL2 or OpenGL3.1) was to deactivate keeping window-previews:

I did not experience any real disadvantages by doing so. On Leap 15.1 the average consumption with a driver a bit older was still lower by 4% to 5%. We talk about 2 Watt here, but still I do not like such unexpected changes. I do not know whose fault this is – KDE’s or Nvidia’s. We shall see what happens with the next driver version ….

Reconfigure KDE settings

The screen order on my Plasma 5.18 desktop was OK. No screen-tearing (see: Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing); my old “xorg.conf“-settings were respected and active.

However, when trying to change design- and plasma-style-settings via “systemsettings5” a click on the “plasma-style”-icon led to a window crash and a Plasma error. This is usually a sign that something is wrong with the KDE configuration files:

Because the KDE setting- and configuration files in the home-directory survive the upgrade untouched some may not be compatible with the new KDE version.

I do not know about an easy way to find out which of the files are to be recreated. My standard way is to make a copy of the “~/.config-directory (with a new suitable name), delete the original directory, wait until it is automatically created again (with new default settings). We
make a copy of this new default-“.config” version (with a unique name), too, and then copy the original version into its standard place again. In the end we have 3 “.config”- directories with different names – one in place with the user’s original settings, one with the new default settings and one with the original settings as “.config”.
Then I overwrite files in the “.config”-file with the new default files, at least those for which I suspect some problems – starting with the plasma-specific “plasma…..rc”-files, then the “systemsettingrc”, then “kwinrc”. Thus, the problems with “plasma-style”-settings could be resolved quickly.

I also got some problems with a standard activation of the OpenGL-compositor at the start of the plasma desktop. A change of the respective settings in the “kwinrc”-file helped – especially “Enabled=True”: 

[Compositing]
AnimationSpeed[$d]
Backend=OpenGL
Enabled=true
GLCore=true
GLPreferBufferSwap=a
GLTextureFilter=1
HiddenPreviews=4
OpenGLIsUnsafe=false
WindowsBlockCompositing=false
XRenderSmoothScale=false

Pulseaudio [PA]

A major frustration came up when I tried to start Clementine and listen to some songs – all my PA-settings were gone with the exception of the PA-LADSPA-equalizer. This had partially to do with changes in the Phonon-settings – now to be found under “systemsettings5 >> Audio“. I had to turn off my onboard HD sound card, activate my mainly used Xonar D2X explicitly and also deactivate an existing XFI-Card, too.

The dialog for setting the KDE/Phonon “standard device” have changed once again :-(. You cannot choose priorities for different sources (audio, video, …) any longer. Simplification? I hate this new KDE politics of taking more and more configuration options away from the standard user. I had to make the equalizer the “standard device” in the new dialog to direct all streams (from browsers and players) through this device.

Compare this to the settings in Leap 15.1; see KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink.
In addition: We cannot play test sounds for the various sinks any more. This does no longer work in “YaST Audio” either … I do not call such things progress.

With PA activated “pavucontrol” serves as my primary mixer. It worked more or less as expected though some functionality has been removed there, too. E.g. the ability to remove some input channels completely. Another stupid thing which happens now regarding the default channel for volume adjustment via kmix is now that you may choose “Simultaneous output ….” – but volume controls will affect the Xonar channels, too – at least as long as no device uses the equalizer ….

It took some fiddling until I got back most of my old functionality and sound quality. I found again that its worth to reduce the Clementine input in pavucontrol down to 80% to avoid some oversteering and sound-distortion. Do not forget to set the default channel for sound control with kmix to “Simultaneous output …” for your multi-channel soundcard!

One can in addition install and activate the XFCE-mixer, which basically is a graphical frontend to an alsa mixer. This allows additional shifts of the different channels against each other – performed after pulseaudio’s own mixer settings, namely those of “pavucontrol”.

A major problem with sound and the onboard card:
For some reason a switch from the graphical terminal to a console terminal (by “Ctrl Alt F3”) automatically
activates an Nvidia HDMI stereo device on my system now. It comes up again even if I explicitly deactivated it in the KDE or PA audio settings. I have no solution for this, yet. It affects, however, at least a running Chromium (see below) – and leads to a restart of desktop effects when I return to the graphical session. I get a corresponding explicit message from Plasma ….

VMware – a yearly game of money …

VMware Workstation 15.5 Pro does not work on a Leap 15.2 host without special prerequisites. See e.g.:
https://forums.opensuse.org/showthread.php/540779-vmware-worksation-pro-15-5-not-failed
https://www.opensuse-forum.de/thread/63542-vmware-workstation-pro-leap-15-2b/?pageNo=1
https://communities.vmware.com/t5/VMware-Workstation-Pro/Can-t-compile-wmware-workstation-15-5-on-leap-15-2/m-p/2286237

However, WS Pro 16.0 does. I upgraded to this version. My Win 10 guests felt a bit more sluggish than with WS 15.5. But this may also have to do with a subsequent Upgrade of Win 10 to the 2004 version.

By the way: Note that VMware wants you to pay extra maintenance support, if you order it from SW resellers – at least here in Germany. The cheapest choice was to order it directly from the VMware shop. Do we like such anti-competition monopoly and customer control measures? No, we do not like it => time to get Windows 10 guests running on KVM machines … and to forget VMware for the future. See:
https://getlabsdone.com/10-easy-steps-to-install-windows-10-on-linux-kvm/#Customizing-the-Hardware-for-Windows-10

Hint: Be a bit reluctant with changing the HW compatibility of your VMware virtual machine for two reasons: You may want the virtual image to continue running in your old 15.1 implementation, too – until you feel that Leap 15.2 is stable enough. Second reason: Changing too much of HW settings may lead to a reactivation of your Windows license key.

CUPS bug – reconfigure printers – use the CUPS packages from the printing repository

I have two printers in my network. They can be addressed both by a local configuration and via a cups server in the net, which offers a variety of queues.
The reconfiguration of the local settings were a piece of cake with YaST. The updated HP-drivers simply worked.
However, printing from my system via a CUPS server in the net and its queues did not work any more. In contrast to all previous upgrades of at least the last 4 years :-(.
It took me a while to find out that this is due to a major bug in the present CUPS version delivered by the standard Update repository of Opensuse. Use the CUPS version > 2.3.0 from the “Printing repository“.
Then your server based queues will work again!

Chromium: Problems with HW acceleration / sound from Chromium does not get upmixed on a multichannel sound card

I had some problems with Chromium. Maybe I had them already before, but I noticed them now:
I had to refrain from HW-acceleration: Whenever I changed to one of the console terminals (e.g. Ctrl-Alt-F2) and returned to the graphical terminal the Chromium user interface got totally destroyed. Not funny when you were editing a blog :-(.
In addition: Chromium sound does not get upmixed completely – the probable reason is that Chromium supports real 7.1 channel sound these days. So, stereo may remain stereo or only gets upmixed by some special soundcard setting to 4.0, 6.0 – but not by PA. Despite such
settings on my Xonar card, I had some disturbing experiences: When changing to a console terminal and back to the graphical one, the upmixing changed from 4.0 to 2.0 …. :-(. When I rebooted afterwards, the 4.0 upmixing was there again. The whole effect probably was due to an automatic activation of some onboard/oncard Nvidia HDMI sound channels during the switch to the console terminals.

Firefox sound, however, which sends a pure stereo signal to the system as, gets properly upmixed by PA to 7.1 sound and this remains stable during switches between console and graphical terminals. So, for the time being, I do not use chromium for TV streaming any longer. Maybe the Chromium developers should have a talk with the PA developer …. It seems to be a difficult problem to me – you would have to analyze that only stereo sound is coming despite a 8 channel signal. A simple workaround would be that we get a switch in the chromium browser which allows to set its operation from multichannel to stereo, only.

For those who like to experiment with “pactl” commands (like “pactl list sinks” as standard user) I would like to draw your attention to work others ave done regarding PA and upmixing:
https://gist.github.com/dex4er/8646669
https://bbs.archlinux.de/viewtopic.php?id=16093

It should be possible to write two scripts one activating a certain upmixing with pactl commands and one deactivating it again. But my time is so limited that I haven’t tried it myself, yet.

KDE Plasma, Nvidia and Wayland do not work

As with Leap 15.1, KDE and Wayland lead to a direct crash on my workstation with Nividia graphics. The system freezes. You have to enforce a reset of your PC and start a reboot. However, on a laptop with a i915 Intel driver for a CPU integrated graphics Wayland works. So, we have a clear Nvidia topic here.

After the upgrade: Make the copy of our original partition of Leap 15.1 a bootable one

If you had copied your original Leap 15.1 partition into another partition on your hard disk you may want to make it a bootable fully functional system offered as an entry in the Grub2 menu. This requires some additional efforts.

Firstly, you have to change all references to the modified UUID in the internal boot-relevant files of the moved filesystem – i.e. in the “/etc/fstab”  AND  in the “/boot/grub2/grub.cfg” there on the Leap 15.1-partition. For this purpose you must mount the copied Leap 15.1 partition on your running Leap 15.2 system and edit the entries in both files of the mounted Leap 15.1 filesystem very carefully with respect to the changed UUID (see the sections on backups above). Take care that you do not change the files on the running Leap 15.2 system. And, please, make copies of both files before you change them! You may need the original contents.

Instead ofchnaging entries in the “/boot/grub2/grub.cfg” of the Leap 15.1 copy you can also rename the “/boot/grub2/grub.conf” on the Leap 15.1 partition to something like “grub.conf_orig” (you want to keep the contents!). This gives the grub “os-prober” on you Leap 15.2 installation a chance to create correct entries regarding the address of the partition.

Then we remove the “/boot/grub2/grub.cfg” in the Leap 15.2 installation and run “grub2-mkconfig -o /boot/grub2/grub.cfg” again to give the os-prober there a chance to create valid entries. Please, cou check these entries first before you install the grub loader from your running Leap 15.2 again! If you find correct UUID or other references to the partition the you can reinstall the bootloader. I always do this with YaST. Afterwards you should be able to boot both your new Leap 15.2 and your old 15.1 installation a respective entries in the Grub2 menu. Thus we have our old Leap 15.1
installation available for comparisons.

Conclusion

An upgrade of a Linux workstation from Opensuse Leap 15.1 to Leap 15.2 brought no major problems with it. One remarkable exception is a bug in the CUPS package – for which you find a solution in form of a newer package in another Suse repository. The fact that Wayland does not work with KDE on Nvidia graphics came not unexpected – although I think its a shame for Nvidia. The same could be said about the increased power consumption of the Nvidia card.

Have fun with Leap 15.2.