Linux Mint 19 alias „Tara“ erschienen

Linux Mint, der Hersteller der gleichnamigen Linux-Distribution, gab am Freitag die allgemeine Verfügbarkeit einer neuen Version ihres Betriebssystems bekannt. Unter dem Namen Linux Mint 19 „Tara“ bietet die neue Version eine Reihe neuer Funktionen, Verbesserungen und ein Versprechen, dass sie noch eine Weile halten wird.

LTS Version von Mint

Brian Fagioli schrieb bei BetaNews:
„Der wichtigste Aspekt von Linux Mint 19 ist die neue Ubuntu 18.04 LTS Basis. Tara wird bis 2023 Updates erhalten – sehr beeindruckend. Der Kernel ist auf 4.15, und alle drei Desktop-Umgebungen werden ebenfalls aktualisiert. Mate ist jetzt in Version 1.2, Cinnamon wird auf 3.8 erhöht und Xfce auf 4.12 aktualisiert.“

Neue Funktionen

Die neue Vorzeigefunktion ist „Timeshift“, was System SnapShots nutzt, um im Falle eines defekten Updates, das System in den letzten fuktionierenden Zustand zurückversetzt zuwerden. Ob es das wirklich bringen wird, wird nur die Zeit zeigen. Vermutlich sind die Probleme, die sich dadurch ergeben werden, so wie bei Systemd oder Wayland, noch gar nicht voll erfaßt worden, trotzdem wird es jetzt durchs Linuxdorf gehypt 🙂

Solange man selbst nicht von dem Testlauf betroffen ist, kann man sich jetzt entspannt zurück lehnen und abwarten wie es ausgeht 😉 Es wäre ja immerhin möglich, daß es tatsächlich der bessere Weg ist. Da ich in 7 Jahren Linux Desktop erst einen kompletten Crash durch ein OS Upgrade erlebt habe, sehe ich da persönlich nicht viel Verbesserungspotential, weil ein „dnf downgrade“ tut es in so einem Fall meistens auch und dessen Folgen sind vorhersagbar.

Gesehen bei SlashDot. übersetzt mit www.DeepL.com/Translator, verfeinert durch Marius 😉

Systemd : The Revenge of Mariadb III

Ich möchte Euch heute eine kleine Weihnachtsgeschichte erzählen, die sich so im Linux Lande Fedora zugetragen hat. Um diese Geschichte zu verstehen, solltet Ihr Euch in diese Vorgeschichte von Mariadb eingelesen haben. Die Geschichte wird Euch lehren, Euch nicht mit dem SystemD anzulegen, denn er wird Euer Ende sein ..

Also, sprach der Admin …

Es ist mal wieder kurz vor Weihnachten. Der erste Schnee fiel schon auf den Boden, da trug es sich zu, daß ein älteres Fedora-System ein Upgrade brauchte. Also hisste der Admin die Wartungsflagge des Servers und begab sich an die Konsole. „Hmm..“  sprach zu seinem Monitor, „der Server ist alt, und wir könnten zwei Versionen überspringen, und damit viel Zeit sparen.“ Auf dem Monitor lächelte ihn seine Reflektion erfreut an und so ward dnf beauftragt, die OS-Release um zunächst zwei Stufen anzuheben.

Dnf tat wie ihm befohlen und ackerte um die gewünschten Pakete zu installieren. Nach 20 Minuten, war das Werk getan und der Admin beauftragte den Server sich neu zu starten. Er tat wie befohlen.

Nach dem Reboot, ist vor dem nächsten Reboot

In freudiger Erwartung, loggte sich der Admin wieder auf seinen Server ein. Tomcat lief, Cron lief, die Datenbank… lief.. und so startete der Admin die Post-Reboot Prozeduren, um die neue MariaDB Version zu initialisieren, das PHP zu setupen, die Chroot zu füllen und sich seinem eigentlichen Ziel, dem DNS Server zu widmen.

Nach einiger Zeit sagte sein treuer Freund pstree erstaunt zu Ihm : „Aber oh Herr, siehe. Der PowerDNS will nicht antworten, obwohl er läuft.“ Der Admin war geneigt an einen kleinen Post-Upgrade Bug zu glauben und startete den PowerDNS neu. Aber auch das zeigte keine Wirkung. Der Prozess blieb stumm. Wieder war es pstree, das aufgeregt zu ihm rief:  „Meister, Mariadb läuft gar nicht, wie soll PowerDNS da antworten?“

Und so befahl der Admin dem SystemD MariaDB neu zu starten. Er tat wie ihm geheißen, kehrte aber nicht von seinem Auftrage zurück. Auch nach 5 Minuten, blieb der SystemD auf dem Wege der Arbeit verschollen. Unruhe machte sich beim Admin breit. Wieso kam SystemD nicht von seinem Job zurück? Was konnte ihm nur passiert sein?

Auf der Suche nach dem Timeout

Also fragt der Admin den journald, was denn dem Systemd zugestoßen sein könnte. Aber der journald wußte es nicht. Ihn hatte keiner einen Fehler gemeldet. Unterdessen meldete sich pstree und sagte: „Herr, so freue Dich. MariaDB ist wieder da. Und PowerDNS antwortet auch wieder! “ . Der Admin schaute auf den Monitor und brummte ein „Hmmmm“ vor sich hin, als der Job endlich zurück kam. Aber was war das ? Weder MariaDB noch PowerDNS funktionierten noch.

Ein schnelles „systemctl status mariadb“ zeigte nur einen „Fehler 203/Exited“ an, und meinte es sei per Signal beendet worden. Wieder dieses „hmmm“ , diesmal von Reflex auf dem Monitor. „Danke“, sagte der Admin laut. pstree sprang aufgeregt durch die Konsole, nichts ging mehr, das war zuviel für ihn. „Komm wieder runter Tree, ich starts nochmal“. Aber auch das brachte nur das gleiche Ergebnis.

Der SystemD war, oder?

Dann durchfuhr es den Admin wie einen Blitz: „Das ist das verdammte Prozesslimit vom SystemD! Das wars doch beim letzten mal auch !“ Gesagt, geändert. Kein Erfolg! Der Admin wurde nervös. Tree hatte sich bereits in die weit entfernteste Konsole zurückgezogen. „Wir haben doch damals eine eigene Limit.conf gemacht.. wo war die nochmal .. ach ja, /etc/systemd/system/mariadb.d/ … könnte es sein, daß sich das Servicefile geändert hat und jetzt irgendeinen Timeoutmist macht ? “ murmelte der Admin zu seinem Abbild auf dem Monitor.

Ein kurzes „diff /usr/lib/systemd/system/mariadb.service /etc/systemd/system/mariadb.service “ erhellte die Mine des Admin.. „JA, DAS WARS“. Endlich. Das eigene Unitfile war derart veraltet, weil es für zwei OS Releases früher gemacht war, daß der Systemd einen falschen Weg zum Start einschlagen mußte. Als der Admin das File entfernte und den Dienst startete, sprang Tree jubilierend aus seiner Konsole. Es war geschafft !

Merke, wenn es um MariaDB geht, versteht der SystemD keinen Spaß. Also halte Dich immer an die Anleitung, wenn Du die Limits konform einbauen willst. Außerdem: MariaDB macht immer nur Ärger beim Update ! Aber wieso immer zu Weihnachten ??!?!?! 😀

 

gleiche RPMs aus verschiedenen Quellen

Ein bisschen speziell ist unser heutiger Fall von Systemupgrade. Wir haben mehrere Repositories/Quellen von RPM Paketen für ein Paket, wollen aber das System per DNF upgraden und ein Paket aus einem bestimmten Repo benutzen.

Das Problem

Wir haben Fedora 25 als OS mit dem Default PHP von Fedora und zwei anderen PHP Versionen von Remi, einem französischen Repository für Serversoftware. Ein Serverupgrade kann man leicht mit

dnf –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

durchführen. Damit alle zusätzlichen Rpms von Drittrepos auch mitkommen beim Update, muß das jeweilige Repo global aktiviert sein, oder man gibt es in der Zeile mit an :

dnf –enablerepo=remi –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

Wenn man das in unserer Ausgangssituation tut, bekommt man einen Quellwechsel ins Spiel, denn man nicht unbedingt haben will. Remi hat nämlich eine neuere Version von PHP als das Fedorarepo.

Der Unterschied

Das hat natürlich einen Grund, Remi hat sich genau dem gewidmet, neigt aber dazu ohne umfangreiche Testrepos zuarbeiten. Fedora dagegen hat eine Communitytestumgebung, auf der Tester die Pakete bewerten müssen, bevor Sie ins Stablerepo gepusht werden.

Fedora hat also ggf. die stabiler laufenden Pakete, weil überhaupt jemand mal testhalber so ein Paket installiert hat. Auf einer Serverumgebung wollen wir natürlich genau dies haben, außerdem könnten die Remi Pakete anders kompiliert sein, und daher unerwartete Nebenwirkungen haben, was strikt zu vermeiden ist.

Quellrepowechsel verhindern

Gibt man jetzt das Upgradekommando ein und hat alle Quellrepos aktiviert, sieht Dnf das „neuere“ PHP Paket bei Remi und wechselt die Quelle, genauso, also wenn man das Testrepository aktiviert und dort ein neueres Paket vorhanden ist.

Daher muß man das Remirepo deaktivieren und erstmal normal upgraden. Nach dem Reboot kann man dann einfach dnf update benutzen um die Pakete zu aktualisieren, die im Remirepo vorhanden sind.

Überraschung

Bei unserem Beispiel F25 zu F26 und PHP kommt es zu einem Versionssprung von PHP 7 auf PHP 7.1 . Damit haben wir jetzt ggf. zweimal 7.1. drauf, einmal von Fedora und einmal von Remi, wo man doch eigentlich 7.0 und 7.1. haben wollte.

Also lösen wir das auf, indem wir 7.1 von Remi entfernen und 7.0 aufspielen:

dnf –enablerepo=remi update php56* php72*
dnf –enablerepo=remi erase php71*
dnf –enablerepo=remi install -y php70-php-process php70-php-cli php70-runtime php70-php-imap php70-php-common php70 php70-php-pdo php70-php-mbstring php70-php-json php70-php-pear php70-php-gd php70-php-mcrypt php70-php-mysqlnd php70-php-xml

Glückwunsch. Sie haben jetzt vier PHP Versionen auf Ihrem Server 😀

Mit FedUP, dem eigentlichen Upgradetool, hätte man das so nicht geschafft, da wäre das PHP dann auch von Remi gekommen.

DNF: Upgradeprozess unterbrechbar

Neulich hatte ich den Worst Case Fall den man sich bei einem Update eines Os’s vorstellen kann: aus  Versehen CTRL-C gedrückt.

Bei ca.1940 Schritten von rund 6500 geschah es… dabei wollte ich nur in einem anderen Fenster die IO-Leistung der SSD während des Updates anschauen und das dortige Programm abbrechen. Zum Glück, muss man sagen, ist DNF an der Stelle noch in der Lage gewesen, einfach bei der Stelle weiterzumachen, wo es aufgehört hat und das Update dann doch noch durchzuführen.

Also, ein großes Lob an die DNF Entwickler.

Nach dem Booten von Fedora 24 kamen dann allerdings auch die mit der Unterbrechung einhergehenden Fehler ans Licht, die sich aber im Rahmen hielten:

FC24 Bootkernel nicht in Grub eingetragen
Initramfs nicht mit meinem Plymouththeme versehen
eine Lib nicht installiert

Der Rest lief überraschenderweise gleich. Alles in allem, trotz Worst-Case-Szenario kein Beinbruch. Vielleicht wars auch nicht der Worst-Case, der wäre wohl dann noch ein Stromausfall gewesen, aber dicht dran wars schon.

Upgrade auf Fedora 24

Ein paar Worte vorweg:

Es gibt mehrere Wege seinen Rechner zu upgraden. DNF zu benutzen ist nur einer davon. Da ich seit Fedora 15 Upgrades per YUM und DNF mache, nehm ich diesen Weg.
Alternativ kann man auch FedUP benutzen. Bei YUM ging bislang alles rutschfrei, auch wenn die Fedora Webseite meint, daß DNF nicht der empfohlene Weg wäre. Letztlich macht aber auch Fedup nichts anderes, da kann man es auch gleich nehmen.

Warnung: Ein Upgrade ist naturgemäß eine destruktive Sache.

Geht es mitten im Upgradeprozess schief, ist das System üblicherweise hinüber. Deswegen: BACKUP machen.

Wenn es dagegen z.b. beim Download der neuen Pakete Probleme gibt, passiert nichts wildes, weil der Upgradeprozess vor dem eigentlichen Upgrade erstmal prüft, ob alles nötige vorhanden ist.

Um sein System auf Fedora 24 zu aktualisieren, braucht man lediglich eine Kommandokonsole (Terminal) und ausreichend Platz auf der Festplatte.

Als erstes sollte man ein Systembackup machen:

cd /
tar czvf /home/backup_sys.fc23.tgz –exclude=sys –exclude=proc –exclude=home *

idealerweise räumt man vorher noch Tempfiles auf und löscht Programme, die man eh nicht mehr benutzen will, aber nie einen Grund, sah sie zu entfernen. Jetzt wäre der richtige Zeitpunkt.

Vor dem Upgrade bitte sicherstellen, daß die Externen Repositories auch bereits alle Fedora 24 unterstützen, weil sonst fehlen ggf. am Ende Programme, die Ihr nutzen wolltet/müßt.
GANZ wichtig, wenn Ihr Nvidia Treiber von RPMFusion benutzt.

Ok. Alles gepüft ? Gut, dann kann es losgehen :

rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-$(uname -i);
dnf upgrade;dnf clean all;dnf –releasever=24 –setopt=deltarpm=false distro-sync –allowerasing

Es kommen einige Fragen, ob man die neuen Keys bestätigen will; Ja, wollt Ihr.. und dann, obs wirklich losgehen kann. Einmal bestätigt, lädt dnf jetzt alles Files runter. Bei meinem Laptop waren es 3.3 GB und rund 4500 Updateschritte. Mit 50 Mbps und SSD dauert das zusammen ca. 25 Minuten.

Ist der Prozess durchgelaufen, einfach Rechner per Reboot neu starten. Fertig.

Die After-Upgrade-Schlacht

Mein Laptop hat brav gebootet, geht soweit wieder, aber was ist das ? Der Gnome Desktop sieht so leer aus…  ? ok, die Apps sind veraltet.

Einmal bitte http://extentions.gnome.org aufrufen, auf „installed Extentions“ gehen und Updates einspielen.

Tip: App nicht gleich löschen, nur weil noch kein Update da ist. Die können einige Zeit brauchen. Einfach in 2 Wochen noch mal nachsehen.

Für die Probleme mit QMMP gibt es morgen einen eigenen Beitrag.

 

Mehr Fedora gibt es hier : http://fedoraproject.org/