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

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 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 :

 *<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 “” 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|] Valid metadata not found at specified URL
 - [openSUSE_Leap_${releasever}_1|] 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|] Valid metadata not found at specified URL
 - [openSUSE_Leap_${releasever}_3|] 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.

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 “”. The graphics repository has found a new location at,

the XFCE at

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.${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.


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!


Wayland vs. Xorg xorg-x11-wayland-linux-display-servers-and-protocols-explained/

Apache2 and PHP8 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-Zeit – Vorsorge durch Fallback-Installationen – II

Im letzten Beitrag
Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I
hatte ich versucht darzustellen, wie man mehrere parallele, bootfähige Linux-Installationen auf einem Einzelplatzsystem (PC, Laptop) nutzen kann, um die Arbeitsfähigkeit im Fall von Update/Upgrade-Problemen zu sichern. Man arbeitet normalerweise auf einer “Hauptinstallation“, die zu einer bestimmten Partition (z.B. “/dev/sdf7”) gehört.

Eine Fallback-Installation auf einer separaten Partition (z.B. “/dev/sdf9”) wird dagegen zu geeigneten Zeitpunkten als Abbild (Partitionskopie) eines funktionierenden Zustands der Hauptinstallation erzeugt und danach hinsichtlich von Updates extrem konservativ behandelt.

Updates/Upgrades werden grundsätzlich erst in einer dritten “Experimental-Installation” (z.B. auf “/dev/sdf3”) für Experimente getestet, bevor sie in der Hauptinstallation nachgezogen werden.

Nutz- und Projektdaten des/der Anwender werden dagegen auf speziellen Datenpartitionen untergebracht, die man in den jeweiligen Installationen bei oder nach einem Bootvorgang auf vorgegebene Knoten des Verzeichnisbaumes mountet. Das geschieht auf Basis gleichartiger Einträge für die Datenpartition(en) in den “/etc/fstab”-Dateien der verschiedenen Installationen; z.B.

myexp:~ # cat /etc/fstab
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 

Diese Einträge werden beim Kopieren der entstehen im Rahmen der Erstellung der Fallback- und Experimental-Installation als Kopie der Hauptinstallation automatisch übernommen.

Ablauf zur Erstellung und Nutzung der Fallback- und der Experimental-Installation

Der Ablauf zur Erstellung und Nutzung der verschiedenen Installationen (auf jeweils unterschiedlichen Partitionen) ist in folgender Abbildung dargestellt:

Die Kuchendiagramme deuten die (wachsende) Partitionsverteilung an. Wir gehen nachfolgend auf einige wichtige Punkte ein, die bei der Erstellung von Partitionskopien als Grundlage der Fallback- und Experimental-Installation zu beachten sind.

Erstimplementierung Hauptinstallation plus Rettungssystem/Minimalinstallation

Die Erst-Installation eines Linux-Systems (z.B. Opensuse Leap 42.2) erfolgt wie üblich aus dem Netz oder per DVD. Man richtet dann seine Datenpartitionen ein und legt zugehörige Mount-Einträge in der “/etc/fstab” fest. Unter Opensuse unterstützt einen dabei der YaST-Partitioner. Dann “gewöhnt” man sich an das neue System und führt erste sinnvolle Updates durch.

Für die Erstellung der Fallback-Installation wollen wir den Inhalt der Partition, die die Hauptinstallation in einem definierten Zustand enthält, in eine andere (freie) Partition kopieren. Eine Kopie des gemounteten Root-Filesystems kann und sollte aber nicht aus der laufenden Hauptinstallation heraus erstellt werden. Der Grund ist einfach: Während der Kopie würden im Hintergrund stattfindende Schreiboperationen beim Kopieren nicht konsistent abgebildet werden. Das gleiche Thema gibt es ja bereits für Backups.

Wir benötigen daher eine weitere unabhängige Minimalinstallation (ohne grafischen Schnickschnack) in einer separaten Partition. Das dortige System booten wir dann zum Erstellen von Kopien anderer nicht gemounteter Partitionen. Alternativ können wir zum Kopieren natürlich auch ein ein Linux-Live-System einsetzen. Für Opensuse
Tumbleweed existieren entsprechende ISO-Images (siehe

Eine andere Alternative bietet ein Rettungssystem, wie es auf Installations-DVDs etlicher Distributionen vorhanden ist. Ein Rettungs- oder Live-System ist aber auch leicht zu erstellen (s. etwa,,

Hat man später bereits eine Experimental-Installation angelegt, so kann man natürlich auch die einsetzen, um die Partition der Hauptinstallation für eine Fallback-Installation auf eine andere Partition zu kopieren.

Partition für Kopie der Hauptinstallation erstellen

Eine Fallback-Installation entsteht am einfachsten durch Kopie der Partition mit der Hauptinstallation auf eine andere (Ziel-) Partition – und einige nachfolgende Schritte. Die Ziel-Partition muss man natürlich vor dem Kopiervorgang angelegt haben. Hierbei ist folgender Punkt wichtig:

Die Zielpartition muss mindestens die gleiche Größe haben wie die Original-Partition; die Zielpartition kann aber auch größer sein. Das gewährleistet man bei der Erstellung durch geeignete Wahl des Start- und Zielsektors (bzw. des Start- und End-Zylinders). Die Differenz – also die Anzahl der Sektoren (bzw. Zylinder) in der Zielpartition – sollte den gleichen Wert haben wie beim Original.

(Das Zusammenfallen von Partitionsgrenzen mit Zylindergrenzen ist ein Spezialthema für HDs mit MBR und sog. CHS-Adressierung; ich kann hier nicht darauf eingehen. Partitionierungstools achten in der Regel bei der Partitionsanlage auf eine entsprechende Optimierung. Auf Platten mit GPT-Partitionstabelle und LBA-Adressierung operiert man sehr viel einfacher mit Sektoren.)

Es gibt eine Reihe von Tools, um Partitionen aufzulisten, anzulegen und zu verändern. Für Opensuse hatten wir ja schon den “YaST-Partitioner” erwähnt. Interessanterweise bietet dieses Tool eine Dimensionierung neuer GPT-Partitionen über die Eingabe von Start/End-Zylinder an. Ein distributionsübergreifendes grafisches Tool ist “gparted” (welches auf dem CLI-Tool “parted” aufsetzt). gparted unterstützt natürlich GPT-HDs/SSDs und zeigt Start- und End-Sektoren für Partitionen an.

Daneben findet sich das CLI-Tool “fdisk“, das inzwischen auch mit GPT-Disks umgehen kann. Speziell für GPT-HDs/SSDS ist das CLI-Tool “gdisk” gedacht. Auch mit gdisk können wir die Größe neuer Partitionen präzise über Angaben zu Sektoren festlegen.

Die Sektor-Information sieht z.B. für zwei gleich große Partitionen “dev/sdf3”, “/dev/sdf7” einer Platte “/dev/sdf” unter fdisk wie folgt aus:

myexp:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 04AD1B2B-6934-444D-BD93-83FE4A3AE15C

Device         Start       End   Sectors  Size Type
/dev/sdf3  171960320 339742719 167782400   80G Linux filesystem
/dev/sdf7  507590656 675373055 167782400   80G Linux filesystem

Ich ziehe auf GPT-Platten für eine präzise Dimensionierung jedoch meist “gdisk”

myexp:~ # gdisk -l /dev/sdf 
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 286739053 sectors (136.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   3       171960320       339742719   80.0 GiB    8300  primary
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
myexp:~ #
myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 7
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 85C6892A-D709-4A3F-9758-D521A7A11F68
First sector: 507590656 (at 242.0 GiB)
Last sector: 675373055 (at 322.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Command (? for help): i
Partition number (1-8): 3
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4C6C4872-1C36-465A-A09F-7CC0EF542E4D
First sector: 171960320 (at 82.0 GiB)
Last sector: 339742719 (at 162.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Wie erstellt man nun eine weitere neue Partition mit identischer Größe? Wir machen das mal versuchsweise mit “gdisk”; dort gibt es dafür das Subkommando “n” (für “new”). Ein Blick in die man-Seiten zu “gdisk” zeigt übrigens auch, dass Änderungen erst dann wirksam werden, wenn wir unter gdisk abschließend den “w”-Befehl absetzen.

myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
Found valid GPT with protective MBR; using GPT.
Command (? for help): n
Partition number (9-128, default 9): 
First sector (34-1000215182, default = 717672448) or {+-}size{KMGTP}: 
Last sector (717672448-1000215182, default = 1000215182) or {+-}size{KMGTP}: +167782400
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 118956653 sectors (56.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   3       171960320       339742719   80.0 GiB    8300  primary
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
   9       717672448       885454847   80.0 GiB    8300  Linux filesystem

Command (? for help): i
Partition number (1-9): 9
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 696C551B-591D-4411-A951-18D337F548D9
First sector: 717672448 (
at 342.2 GiB)
Last sector: 885454847 (at 422.2 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

Command (? for help): q

Man beachte hier die GUID, die eine Partition in eindeutiger Weise auf einem Device identifiziert. Die GUID ist von einer sog. “UUID” des Filesystems (s.u.) in einer Partition zu unterscheiden !

Schreibt man die geänderte Partitionstabelle im letzten Schritt tatsächlich mit “w” auf die Platte, informiert “gdisk” den laufenden Kernel nicht über die Änderungen! Das geschähe ohne weitere Maßnahmen erst bei einem Reboot. Will man das vermeiden, hilft das CLI-Kommando “partprobe“, das zusammen mit dem Tool “parted” installiert wird.

myexp:~ # partprobe /dev/sdf 

es geht alternativ auch

myexp:~ # /sbin/blockdev --rereadpt /dev/sdf

Kopieren der Partition mit der Hauptinstallation mit Hilfe des CLI-Kommandos “dd”

Ein “geeigneter Zeitpunkt” zum Erstellen einer Kopie der Hauptinstallation ergibt sich im laufenden Betrieb im Zuge von Updates nach einer Phase zufriedenstellender täglicher Arbeit. Steht man vor einer Upgrade-Aktion für sein Linux-System, wird man die laufende Hauptinstallation in jedem Fall kopieren und daraus eine bootfähige Fallback-Installation herstellen.

Für eine bitweise Kopie ist der Einsatz des CLI-Kommandos “dd” am einfachsten. Siehe zu einer Einführung bzgl. “dd” etwa und “dd” ist unter Linux ein wirkliches wichtiges Werkzeug, das man in Kombination mit “gzip” und “tar” nicht zuletzt auch für die Erzeugung von Updates nutzen kann! Man sehe sich also zu “dd” unbedingt mal die man-Seiten und auch unten angegebene Links an.

Nehmen wir an, unsere aktuell benutzte Hauptinstallation liegt auf einer Partition “/dev/sdf7”. Auf der gleichen Platte befinde sich bereits eine Partition “dev/sdf9” gleicher Größe (man prüfe hierzu die Sektor- oder Zylinderanzahl in einem Partitionierungstool; s.o.). Aktuell gebootet worden sei eine Installation auf einer Partition “/dev/sdax” (x im Beispiel ungleich 7 oder 9) oder eben ein Live- oder Rettungs-System. Im gebooteten System erreicht man dann eine bitweise Kopie von “/dev/sdf7” auf “/dev/sdf9” per

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M

Zum Parameter “bs” siehe die man-Seiten! Auf einer optimal angebundenen SSD dauert ein solcher Kopier-Prozess für eine “80 GByte”-Partition deutlich weniger als 10 Minuten.

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M
81925+0 records in
81925+0 records out
85904588800 bytes (86 GB, 80 GiB) copied, 418.97 s, 205 MB/s

Die SSD operiert hier mit ca. 400 MB/s, da sie ja lesen und schreiben muss.

Haben wir damit schon unsere gewünschte “Fallback-Installation” erstellt? Da wir ja mit der Partition auch das dortige Filesystem samt Inhalten bitweise kopiert haben, könnte man meinen, dass mit der Kopie schon alles erledigt sei – und man nur noch den Bootmanager “Grub2” unter Einbeziehung aller verfügbaren OS-Installationen (z.B. mittels YaST2 >> Bootloader” neu schreiben lassen muss.

Das ist ein gewaltiger Irrtum!:

Warnung: Bitte schreibt nach Kopie einer Partition mit einer Betriebssysteminstallation nicht den Boot-Manager neu – und schon gar nicht unter Einbeziehung aller bootbaren Filesysteme.

Warum? Die Antwort gibt der nächste Abschnitt …

Vermeidung gleicher UUIDs
verschiedener Filesysteme nach dem Kopieren von Partitionen

Wenn wir eine Partition bitweise kopieren, wird der gesamte Inhalt (Filesystem + dessen Inhalte) 1:1 in die Zielpartition übertragen. Jedes Filesystem hat nun aber eine ID, die sog. “UUID“, die in einem System eindeutig sein sollte.

Die UUID eine Filesystems ist eine (hoffentlich eindeutige) Kombination aus alphanumerischen Zeichen. S. die nachfolgende Abbildung:

Die UUID vorhandener Partitionen kann man sich mit vielen Partitionstools und auch dem Kommando “tune2fs” anzeigen lassen. Ein geeignetes Kommando für die Kommandozeile ist aber auch “blkid“. Testet man unmittelbar nach unserem Kopiervorgang von “/dev/sdf7” auf “/dev/sdf9”, so erhält man

myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Diese leider von uns selbst erzeugte Uneindeutigkeit hat nach dem Kopiervorgang noch keine unmittelbaren Folgen. Der Befund ist aber dennoch außerordentlich problematisch, denn es gilt:

Aktuelle Linux-Distributionen identifizieren zu mountende oder im Bootprozess anzusprechende Filesysteme (bzw. Partitionen) nämlich genau über die “UUID”.

Siehe zu der Thematik auch: Unter Opensuses “YaST Partitioner” gibt es hierzu übrigens eine Grundeinstellung, die man auch modifizieren kann:

Unter Linux steuert u.a. die Datei “/etc/fstab” bekanntermaßen das Mounten von Filesystemen – u.a. auch des root-Filesystems – in bestimmten Phasen des Systemstart mit. Werden nun die zu mountenden Filesysteme (Partitionen) in der Datei “/etc/fstab” tatsächlich durch UUIDs gekennzeichnet, können schon beim nächsten Bootvorgang ernsthafte Probleme auftreten; es gibt nach unserer Partitionskopie mittels “dd” ja zwei Filesysteme mit derselben UUID!

Noch schlimmer werden die Verhältnisse, wenn wir auch noch die Grub2-Konfiguration unter Einschluss aller bootbaren Installation updaten; das ist dann ein sicherer Weg in den Abgrund; mit Doppelmounts auf “/” und nachfolgenden Katastrophen ist zu rechnen!

Deshalb gilt:

Warnung: Bevor man irgendetwas nach dem bitweisen Kopieren einer Partition in einen andere auf dem Datenträger ein und desselben aktiven Systems unternimmt, sollte man unbedingt die UUID des kopierten Filesystems ändern, sowie die Einträge in den dortigen Dateien “/etc/fstab” und “/boot/grub(2)/grub.cfg” an die neue Situation anpassen.
Nur dann werden wir die kopierten Installationen auch ohne Probleme bootfähig zu bekommen! Auf keinen Fall sollte man vor Erledigung dieser Schritte im aktuell gebooteten System die Bootloader-Konfiguration neu schreiben lassen.

Ändern der UUID im Filesystem der kopierten Partition

Wie ändert man die UUID eines (kopierten) Filesystems? Hierzu braucht man zwei Schritte:

  • Schritt 1: Generieren einer neuen UUID mittels des Befehls “uuidgen
  • Schritt 2: Ändern der UUID auf der kopierten Partition mittels des Kommandos “tune2fs device -U newUUID

Wir führen das mal am Beispiel unseres kopierten Filesystem auf der Partition “/dev/sdf9” durch:

myexp:~ # uuidgen 
myexp:~ # tune2fs /dev/sdf9  -U a65d6a9b-cc87-4af7-95bf-f407f463f344
tune2fs 1.42.11 (09-Jul-2014)
myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="a65d6a9b-cc87-4af7-95bf-f407f463f344" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Damit sind wir aber keineswegs fertig …

Anpassen der Datei “/etc/fstab” und der “/boot/grub2/grub.cfg” im kopierten Filesystem

Bevor wir den Bootloader neu schreiben lassen, ändern wir zunächst die Dateieen “/etc/fstab” und zur Sicherheit auch der “/boot/grub2/grub.cfg” ab. Hierzu mounten wir das frisch kopierte Filesystem im aktuell gebooteten System – z.B. auf “/mnt” -und ersetzen in der dortigen “fstab” (also in der /mnt/etc/fstab”) die Einträge mit der alten UUID:

myexp:~ # mount /dev/sdf9 /mnt
myexp:~ # cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 

Problematisch ist vor allem der zweite Eintrag, der noch die kopierte UUID beinhaltet! Diese UUID ändern wir nun mit Hile eines Editors unserer Wahl auf die neue – per uuigen generierte und per tune2fs zugeordnete – UUID ab:

# cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=a65d6a9b-cc87-4af7-95bf-f407f463f344       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 

Damit haben wir schon mal größeres Unglück verhindert. Eine Anpassung der “/etc/fstab” ist der wichtigste Schritt.

Ganz auf die sichere Seite gegenüber späteren manuell verursachten Fehlern kommen wir aber erst mit entsprechenden Änderungen in der Datei “/mnt/boot/grub2/grub.cfg” – oder aber einer Elimination der Datei für das (versehentliche) Schreiben des Bootloaders unter der neuen Installationm. .

In der “/mnt/boot/grub2/grub.cfg” finden sich Boot-Einträge der Form

menuentry 'openSUSE 42.2 (x86_64) (on /dev/sdf7)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-96c9a3bf-60fe-496e-801c-3a3047ac71a9' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt7 --hint-efi=hd5,gpt7 --hint-baremetal=ahci5,gpt7  96c9a3bf-60fe-496e-801c-3a3047ac71a9
	  search --no-floppy --fs-uuid --set=root 96c9a3bf-60fe-496e-801c-3a3047ac71a9
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9 ro resume=/dev/disk/by-uuid/d9a73a89-b89b-4fda-8c4c-9034e42d1274 splash=silent quiet showopts elevator=deadline intel_pstate=disable swapaccount=1 pti=on
	initrdefi /boot/initrd-4.4.104-18.44-default
submenu 'Advanced options ......

Würden wir diese “grub.cfg” (nach einem Booten der kopierten Installation) dummerweise direkt zur Implementierung des
Bootloaders per “grub-install” nutzen, gäbe es ein vermeidbares Chaos.

In der Datei müssen wir deshalb natürlich alle Strings “96c9a3bf-60fe-496e-801c-3a3047ac71a9” ersetzen durch “a65d6a9b-cc87-4af7-95bf-f407f463f344”. Das geht mit Editoren wie “kate” relativ gefahrlos.

Ein noch einfacherer Schritt zur Absicherung gegenüber späteren potentiellen Unglücken durch manuelle Befehle zum Schreiben des Bootloaders ohne vorherige Neugenerierung der “boot.cfg” ist, die Datei schlicht umzubenennen – und damit für versehentliche Installationen auszuschalten:

myexp:~ # mv /mnt/boot/grub2/grub.cfg /mnt/boot/grub2/grub_before_copy_180219.cfg_orig

Bootfähigkeit der neuen Installation herstellen

Natürlich schreiben wir den Bootloader aber eher von der funktionierenden “ursprünglichen” Hauptinstallation aus. Haben wir die “etc/fstab” in er kopierten Partition auf die neue UUID angepasst, können wir – ohne vorheriges Verändern des Grub2-Bootloaders – unser System getrost neu booten und dabei die ursprüngliche Hauptinstallation starten. Von dort aus nehmen wir nun eine Erweiterung des Bootloaders vor, so dass dei neue “Fallback”-Installation später im Grub2-Bootmenü mit angeboten wird.

Unter Opensuse nutzen wir dazu YaST’s Bootloader-Modul:

Dieses Programm bietet 3 per Reiter (Tabs) erreichbare Konfigurationsseiten an. Die letzte ist für unsere Zwecke am wichtigsten und sieht wie folgt aus:

Hier müssen wir die Option “Fremdes OS testen” abhaken.

[Zu alternativen CLI-Kommandos “grub_mkconfig”, “update-grub” (Ubuntu) bzw. “grub2-mkconfig” (Opensuse) und “grub-install” siehe den letzten Beitrag und die Doku eurer Distribution. Unter Opensuse Leap prüft “grub2-mkconfig” durch Aufruf des “os-prober”-Skripts fremde OS gleich mit und schreibt den gesamten Output defaultmäßig in die “/boot/grub2/grub.cfg”.]

Danach finden wir in der Datei “/boot/grub2/boot.cfg” Einträge folgender Art zum Filesystem auf “/dev/sdf9” vor:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt9'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  a65d6a9b-cc87-4af7-95bf-f407f463f344
	  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
	initrdefi /boot/initrd-4.4.104-18.44-default
submenu 'Erweiterte Optionen für openSUSE 42.2 (x86_64) (auf /dev/sdf9)' $menuentry_id_option 'osprober-gnulinux-advanced-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.104-18.44-default--a65d6a9b-cc87-4af7-95bf-f407f463f344' {
		insmod part_gpt
		insmod ext2
		set root='hd5,gpt9'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  
		  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
		linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
		initrdefi /boot/initrd-4.4.104-18.44-default

Diese Einträge im Boot-Menü hat YaSTs Bootloader-Modul dann auch schon gleich auf der Platte verewigt. Sie werden beim nächsten Bootvorgang mit angeboten.

Damit haben wir unsere durch “dd” erzeugte “Fallback-Installation” auf “/dev/sdf9” bootfähig verankert.

Experimental-Installation und Upgrade

Eine Experimental-Installation” erzeugt man in einer weiteren Partition auf ganz ähnliche Weise wie oben beschreiben und macht auch diese nach UUID-Änderung und Anpassung der dortigen “/etc/fstab” bootfähig. Für die Experimentalinstallation kann man dann eine probeweises Upgrade vornehmen. (Im Beispiel von Opensuse Leap 42.2 auf Leap 42.3 …).

Andere Einstellungen in der “/etc/fstab”

Das “Gefährliche” bestand bei unserem Vorgehen vor allem in der Duplizierung der UUID – und eventuellen diesbezüglichen Einstellungen in der “/etc/fstab”. Natürlich kann man die Einträge in der “/etc/fstab” auch auf Basis konventioneller Laufwerksbezeichnungen (“dev/sdxn”) vornehmen.
Der Yast-Partitioner bietet hierfür sogar eine Einstellungsoption an:

Einträge mit normalwer Bezeichnung sähen so aus:

/dev/sdf9       /       ext4    acl,user_xattr 1 1 

Dies befreit aber aus einer Vielzahl von Gründen nicht davon, die UUID des Filesystems trotzdem abzuändern.

SSDs – und Intervalle für Partitionskopien

Eine Kopie größerer Partitionen durchzuführen ist schreibintensiv. Nicht alle SSDs haben eine hinreichende Qualität, um solche Schritte oft durchführen zu können. Die SSD leidet darunter (wear leveling count). Man sollte die Erstellung einer neuen “Fallback-Installation” als Kopie der Hauptinstallation daher nur in größeren Zeitabständen vornehmen.

Hat man gute Erfahrungen mit Updates sowohl in der Experimental-Installation als auch auf der Hauptinstallation gemacht, spricht ja nichts dagegen, Updates auch auf der Fallback-Installation systematisch und kontrolliert nachzuziehen. Nur vor Upgrades erscheint mir die Anlage einer Fallback-Installation als Kopie der aktuellen Hauptinstallation unvermeidlich.

Ich hoffe, der eine oder andere hat beim Lesen ein paar Dinge aufgeschnappt, die er noch nicht kannte …


Übersicht GPT

Übersicht Linux Partitioning Tools

Partition Alignment

UUID ändern

Backups mit dd