Leap 15.6 – upgrade from Leap 15.5 on laptop with Optimus architecture

The last 4 months I was primarily occupied with physics. I got a bit sloppy regarding upgrades of my Linux systems. An upgrade of an rather old laptop to Leap 15.6 was overdue. This laptop had an Optimus configuration: To display graphics one can use either the dedicated Nvidia card or a CPU-integrated Intel graphics or both via an “offload” option for certain applications.

General steps to perform the upgrade

I just list up some elementary steps for the upgrade of an Opensuse Leap system – without going into details or potential error handling:

Step 1: Make a backup of the present installation
You can, for example, create images of the partitions or LVM volumes that contain your Leap-installation and transfer them to an external disk. Details depend of course on whether and how you have distributed system files over partitions or (LVM) volumes. In the simple case of just one partition, you may simply boot a rescue system, mount an external disk to /mnt and then use the “dd”-command;

# dd status=progress if=/dev/YOUR_PARTITION of=/mnt/bup_leap155.img  bs=4M 

Step 2: Update the installed packages of the present Leap installation
Perform an update of (all) installed packages – if newer versions are available. Check that your system runs flawlessly afterwards.

Step 3: Change the addresses of repositories to use the ${releasever} variable
You can e.g. use YaST to change the release number in the definition of your repositories’ addresses to the variable ${releasever}. The name of the SLES repository may then look like “https://download.opensuse.org/update/leap/${releasever}/sle/”.

Continue reading

Opensuse Leap 15.5 – YaST2 bug – no repositories can be added via YaST2

In one of the last posts I have said that upgrades of running Opensuse Leap 15.4-systems to Leap 15.5 are a smooth business. However, a major bug in the present Leap 15.5 did not appear on my radar until now.

During the upgrades of most of my systems I just continued using a system-specific bunch of active Opensuse repositories – like the “graphics” and the “security” repositories. I used the ${releasever}-mechanism during the upgrades to point zypper to the new versions of the repositories. This all went well and after the upgrade I found the 15.5-versions of those repositories, which I had used on Leap 15.4 before, integrated into the YaST2-software and package management of Leap 15.5.

But, two days ago, I installed Leap 15.5 on a laptop from an ISO-image on a DVD. Such an installation only sets up basic Leap 15.5 repositories. So, after the installation I wanted to add further repositories via YaST2’s software-management. This did not work at all. The repositories simply did not appear in the list of managed repositories afterwards.

I fiddled around for about an hour. It became clear by switching views on repos and so called “services” that the requested new repositories were handled by YaST as SW-services, instead as standard repositories. Whatever “services” are going to be good for in the future. I could find some information at
https://news.opensuse.org/ 2023/07/31/ try-out-cdn-with-opensuse-repos/.

I moved in the end to zypper on the command line to add repositories. Which worked …. A good reason to suspect a bug.

Bug: Adding repositories with YaST2 does not work presently

Indeed: The following two links showed that other Opensuse users had the same problem and that there is a related bug-entry at Opensuse’s bugzilla:
https://forums.opensuse.org/ t/ cant-add-repos/ 171641
https://bugzilla.opensuse.org/ show_bug.cgi?id=1218399

Well, YaST2 is a central tool-box for Opensuse systems. And who would deny that the package manager is one of the most important tools on any Linux system? So, old kinds of questions regarding quality assurance came to my mind: Are changes to central Leap components tested thoroughly at Opensuse? In particular as also SLES is affected …. Unbelievable …

The affected package is yas2-packager 4.5.17-150500.3.3.1.

Workaround

Adding repositories directly via zypper (which is used by YaST2) still works. So, you can add add repositories like the security repository, with command analogous to the following:

mytux:~ # zypper ar -f https://download.opensuse.org/repositories/security/15.5 security
Adding repository 'security' 
..................................................................................[done]
Repository 'security' successfully added

URI         : https://download.opensuse.org/repositories/security/15.5
Enabled     : Yes
GPG Check   : Yes
Autorefresh : Yes
Priority    : 99 (default priority)

Repository priorities are without effect. All enabled repositories share the same priority.

These repos afterward appear in the YaST2 packet manger and are fully usable to install RPM packages.

Weird aspect of the YaST2 packet manager: Opensuse and Nvidia services cannot be deleted via YaST2

After some updates of leap 15.5 you may find that all basic repositories have been switched to “services” at “cdn.opensuse.org”. What is disturbing: A fresh installation of Leap 15.5 from an ISO-image does not show any of the services displayed in the image above.

Once you got the “services” in your Leap 15.5 installation you may want to delete them and restrict your system to the standard repositories at “download.opensuse.org”. But this does not work with YaST2. Which appears as an additional bug. You may switch to “services” and delete them in the views coming up. And everything afterward gives you the impression that they are gone. But no: After a restart of YaST2 and the packet manager all Opensuse services appear restored again.

Conclusion

YaST2’s present packet manager for Leap 15.5 has a major bug: Repositories can not be added. In addition one cannot get rid of the new Opensuse services. Let us hope that we get a new and error free version of YaST2’s packet manager soon.

Opensuse Leap 42.1 – Amarok – Abstürze, Freezes – Wechsel zu Packman Paketen erforderlich

Eine Testapplikation für die Funktionstüchtigkeit neuer KDE-Versionen – wie nun KDE 5 – ist für mich u.a. Amarok. Ich nutze für die Musikberieselung beim Arbeiten in der Regel zwar lieber das übersichtlichere und in seinen Funktionen i.d.R. auch stabilere Clementine. Aber Amarok offenbart oftmals Schwächen im Zusammenspiel mit Phonon und den Phonen-Backends sowie mit Codecs.

Besonders interessant war ein Amarok-Test im vorliegenden Fall für ein frisch installiertes Opensuse Leap-System auch deshalb, weil Amarok nur in der Version 2.8 vorliegt, die meines Wissens eigentlich für KDE 4.14 entwickelt wurde. Unter Leap 42.1 kommt aber KDE 5 zum Einsatz.

Nach meinen ersten Erfahrungen mit Opensuse Leap 42.1 und KDE 5 gilt grundsätzlich: Eigentlich kann man die Pakete, die SuSE einem auf der Leap 42.1-Installations-DVD anbietet, vergessen. Damit bekommt man auf einem etwas komplexeren Desktop-System mit Nvidia-Karte und mehreren Soundkarten jedenfalls kein dauerhaft stabiles und flüssig funktionierendes System mit KDE-Plasma-Desktop hin.

So führte bei mir u.a der Aufruf von Amarok in den Abgrund. Es gab ganz verschiedene und erratisch auftretende Varianten von Fehlern, die ein Amarok-Start (und ggf. auch ein Aufruf des integrierten Equalizers) bei mir auf einer Leap-Standardinstallation provozierte – Absturz des Plasma-Desktops, Freeze des Desktops, Freeze von Amarok, kein Start von Musik-Dateien möglich (weder MP3 noch Ogg Vorbis, noch ….). Mit und ohne Pulseaudio ….

Dabei lief/läuft Clementine auf Anhieb anstandslos. Also war das Sound-System des KDE 5-Desktops wohl grundsätzlich lauffähig. Eine Lösung brachten schließlich folgende Schritte:

  1. Update aller installierten Pakete mit Hilfe der Standard Opensuse Online Repositories.
  2. Packman und VideoLan-Repositories in den YaST-Paketmanager einbinden.
  3. Diverse Codec-Pakete, Lame und was man sonst noch für seine Sound-Applikationen braucht aus dem Packman-Verzeichnis laden.
  4. Wechsel für alle Pakete, bei denen das möglich ist (u.a. zu Gstreamer), von den Versionen der Opensuse Standard- und Upgrade-Repositories zu den Versionen des Packman-Repositories.
    Nachtrag 25.01.2016:
    Es gibt eine bemerkenswerte Ausnahme: Das Paket “freshplayerplugin” sollte man in seinen neuesten Versionen weder aus dem Packman- noch aus dem Multimedia-Repository installieren, wenn man Eclipse Mars mit GTK2 betreiben will. Siehe hierzu einen kommenden, gesonderten Blog-Beitrag.
  5. Löschen sämtlicher “amarokrc”- und relatierter Dateien sowie auch der Datei “.gstreamer-0.10” im eigenen Home-Verzeichnis. Die werden automatisch neu angelegt.
  6. Zur Not einen anderen neuen User aufsetzen und mal für diesen neuen User testen. Bei Erfolg, den ursprünglichen User komplett neu aufsetzen.

Nun laufen sowohl Amarok als auch Clementine.

Dass ich auf Desktop-Systemen außerdem Pulseaudio abschalte (geht am einfachsten über YaST2 und die dortige Sound-Konfiguration) und lieber auf Plain Alsa vertraue, wissen die Leser meines Blogs eh’ schon. Das hat aber mit dem Amarok-Problem und der dahinter liegenden Inkonsistenz diverser Pakete des SuSE-Systems weniger zu tun ….