EOL: Fedora 32 – so upgraded man sein System von Hand

Fedora 32 hat End-of-Live, da kann man mal zeigen wie so ein OS Upgrade von Hand aussieht.

EOL: Fedora 32 – so upgraded man sein System von Hand

Die meisten Fedora Benutzer werden schon lange vor diesem Tag Ihr Updateangebot durch ständiges Nerven bekommen haben. Wer dann auf „Ja, mach doch“ klickt, der verpasst einiges an Aktion und wird nie verstehen, was bei einem Distro-Upgrade so alles passiert.

Für diejenigen, die sich das gerne mal live ansehen wollen, so könnt Ihr dabei sein, aber nur, wenn Ihr auch noch Fedora 32 habt 😉

Den neuen Repo-Key importieren

Da alle Pakete signiert sind, braucht man zum Testen der Signatur einen Key von der neuen Release (33). Praktischerweise ist dieser Schlüssel bereits in der vorherigen Release(32) enthalten und muß nur schnell importiert werden:

rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$(uname -i)

Warum das nicht auch automatisch gemacht wird, sobald ein neuer Key da ist, entzieht sich mir. Wenn Ihr vergessen habt, diesen Schlüssel hinzuzufügen, ist das nicht tragisch. DNF wird Euch im Updateprozess nochmal fragen, ob der Schlüssel hinzugefügt werden soll:

Warnung: /var/cache/dnf/rpmfusion-free-updates-f3bb44067d4cef3b/packages/svt-hevc-libs-1.5.1-1.fc33.x86_64.rpm: Header V3 RSA/SHA1 Signature, Schlüssel-ID d651ff2e: NOKEY
RPM Fusion for Fedora 33 – Free – Updates 1.6 MB/s | 1.7 kB 00:00
GPG-Schlüssel 0xD651FF2E wird importiert:
Benutzer-ID : »RPM Fusion free repository for Fedora (2020) <rpmfusion-buildsys@lists.rpmfusion.org>«
Fingerabdruck: E9A4 91A3 DE24 7814 E7E0 67EA E06F 8ECD D651 FF2E
Von : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-33
Ist dies in Ordnung? [j/N]:

In diesem Fall fragt er nach dem Key von RPMFusion, was man als Fedorabenutzer braucht um z.B. Nvidia-Treiber und MPV zu installieren.

Immer mit screen arbeiten

„screen“ ist ein kleines Konsolen Programm, das Euch im Falle des Falles den Arsch retten kann. Beim Upgradevorgang kann es nämlich passieren, daß der Desktop zusammenbricht. Wenn Ihr jetzt nur in einem Terminalfester die nachfolgenden Befehle eingetippt habt, ohne das Screen an ist, dann bricht der Updatevorgang mitten drin ab.

Im Worst-Case-Fall habt Ihr ein nicht bootbares System vor Euch. Das System kann man reparieren, wenn einen USB-Stick mit einem bootbaren Fedora hat. Kurz beschrieben: die Systemplatte mounten, als Rootuser ein Chroot auf diese Systemplatte, das Update OHNE GRUB ( -x grub2* ) neu starten und zusehen, was weiter passiert.

Screen verhindert das Szenario, weil wenn das Terminal zusammenbricht, läuft Screen im Hintergrund weiter und es kommt gar nicht zur Unterbrechung des Upgradevorganges. Ergo:

screen

Das eigentliche Upgrade

Nun updaten wir erst einmal auf den neuesten Stand:

dnf clean all;dnf -y upgrade;

I.d.R. wird da nichts gemacht, aber falls Updates fehlen sollten, würden die jetzt eingespielt werden. Nun folgt das eigentliche Upgrade:

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

DNF wird jetzt zuerst die neuen Paketinformationen von Fedora 33 holen und dann berechnen wie groß und umfangreich das Upgrade wird. Auf einem Desktopsystem kann das schon einmal größer ausfallen:

Transaktionsübersicht
=============
Installieren 200 Pakete
Aktualisieren 4032 Pakete
Entfernen 12 Pakete

Gesamte Downloadgröße: 7.9 G
Ist dies in Ordnung? [j/N]:

Zum Glück habe ich Platz:

LABEL=SYSTEM 909G 184G 680G 22% /

Was jetzt folgt sind der Download und die eigentliche Aktualisierung.  Weil das hier nur so vorbei zischt, ein Bild für Euch:

Wie Ihr sehen könnt, läuft das Update während ich mit dem System arbeite, z.Z. tippe ich den Text hier 😉

Wie man rechts sehen kann, zeigt einem DNF im Gegensatz zu APT und Konsorten an, wieviele Schritte da noch kommen werden. 50% der Updateschritte sind übrigens „Aufräumen“ der alten Pakete. Die Schrittanzeige ist auch für Unbedarfte ein Vorteil, weil die Geduldsprobe „Desktopupgrade“ erträglicher geworden ist.

Jetzt braucht Ihr natürlich trotzdessen noch Geduld, weil auch mit SSDs brauchen die 8000 Schritte eine ganze Weile und die Hammerpakete wie 0AD, die gleich mal 1-2 GB hinzufügen, sind bei mir schon entfernt. Ich sollte trotzdem mal aufräumen 😉

Bei mit kommt in 4 Minuten der spannende Teil: Der Reboot 😉

Kleines „Ups“ beim Fedorateam

Aus der Schmunzelecke: „Ups, Fedora 32 ist ja schon da“

„Federa 32 ist da“

Einigen Usern von Fedora wurden heute morgen Upgradehinweise auf Fedora 32 eingeblendet. Wer sich jetzt wundert, daß der Releasezeitpunkt noch gar nicht erreicht ist, der liegt richtig 🙂 Das Team um A. Williamson hatte die Ursache zwar schon nach 45min behoben, aber aufgrund diversen Cachings auf dem Weg zum Endnutzer, wurde der Hinweis auf die erst im Sommer erscheinende Fedora Version 32 stundenlang angezeigt.

Da ich auch einige weniger eingeweihte Menschen mit Linux betreue, bin ich froh, daß es für uns in der Nacht ablief und die Meldung folglich keiner bemerkt hat. Wenn das Upgrade auf 32 in dem Zustand erstmal gestartet worden wäre, wäre dem PC-System vermutlich nicht mehr zu helfen gewesen. Schwein gehabt 😀

 

 

The Revenge of Mariadb IV

Es ist mal wieder Zeit für eine MariaDB Geschichte. Keine Panik, die wird nicht wieder biblisch werden 🙂

Es war mal wieder Zeit für ein OS-Upgrade

Mittlerweile waren drei OS-Releases ins Land gegangen und eine sich anbahnende Sicherheitslücke im Exim .. PSSST! Ich habe sie Euch nicht verraten. Tut so, also wenn Ihr nächste Woche das erste mal davon gelesen habt, ja? 😉 .. zwang zu einem schnellen Update auf eine nicht betroffene Version. Fedora 29 sollte es sein 😉

Nun, glücklicherweise war auch ein anderer Testserver noch auf der gleichen alten OS Release, so daß er als Testlauf herhalten durfte. Dieser Test lief ausgesprochen positiv ab, um genau zu sein, makellos. Daher wurde kürzestfristig entschieden, auch den eigentlichen Kandidaten auf die gleiche Art zu updaten. Ein Snapshot der VM und 30 Minuten später  war das Update komplett und der Server startete wieder.

Mailserver, Webserver, IMAP-Server, diverse Dienste liefen. Was natürlich nicht lief war die MariaDB .. Ätzzz. N I C H T  S C  H O N  W I E D E R!   Auch gutes Zureden, energisches Nachtreten mit systemctl änderte nichts an diesem Status, der Datenbankserver startete nicht.

Same procedure als last year, Miss Sophie?

Leider nein. Letztes mal hatte sich bekanntlich ein Konfigfile des Systemd geändert, so daß die zum Start nötigen Limits nicht gesetzt wurden. Natürlich wurde der DIFF Test vom letzten mal auch wieder angewendet, zeigte aber keinen Unterschied an. Also mußte die gute alte Methode „Start den Dienst von Hand, dann bekommst Du Infos“ herhalten.

Wie macht man das?

Wir schauen uns mal an, was der Systemd so starten wollen würde:

cat /usr/lib/systemd/system/mariadb.service

Da findet dann das hier:

ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf
# Note: we set –basedir to prevent probes that might trigger SELinux alarms,
# per bug #547485
ExecStart=/usr/libexec/mysqld –basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
ExecStartPost=/usr/libexec/mysql-check-upgrade

Das POST können wir ignorieren, soweit kommen wir nicht, bleiben nur Pre und der eigentliche Dienststart.

Das in den einschlägigen Envfiles  unter /etc/sysconfig/ nichts steht, reicht also ein :

/usr/libexec/mysqld –basedir=/usr

für den Test aus. Ja super.. eine Fehlermeldung:   Can’t set requested open_files (1024) to 2000 …

Das lag an dem ulimit hier:

# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32088
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 32088
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Damit kann nicht mal die minimale Version der Datenbank starten 😉 Ergo geben wir ein: „ulimit -n 99999“ und starten es nochmal und siehe da, es hat sich doch wieder was geändert:

2019-06-04 23:13:41 0 [ERROR] /usr/libexec/mysqld: unknown variable ‚innodb_additional_mem_pool_size=50M‘
2019-06-04 23:13:41 0 [ERROR] Aborting

Wenn man denn endlich mal in Logfile schaut, sieht man dort auch die Warnung, daß sich das ja mal ändern könnte. Wer rechnet schon mit damit, daß da jemand mal Ernst macht 😉

2019-05-26 09:18:16 b753fd80 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB’s internal memory allocator.
2019-05-26 9:18:16 3075734912 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

Merke, erst ins Datenbank Log schauen, dann Server updaten!

Drei OS-Versionen sind dann vielleicht doch etwas happig bei einem Update. Diese Option findet man, so man sie gesetzt hat, in der Datei /etc/my.cnf . Anweisung auskommentieren, diesmal Datenbank über systemctl starten und läuft wieder 🙂

Und hier dachte ich eigentlich, ist die Story zu ende… war sie aber nicht!

Der an diesem Master angeschlossene Replications Elf ( Sklave sagt man im PCSG nicht mehr 😉 ) mochte die Replikationsblöcke vom Master nicht mehr lesen, weil Checksumme unbekannt! Das lag daran, daß der Replikations Elfe eine ältere Datenbankversion laufen hatte, da LTS. Einer langen Suche kurzes Ende:

Elfen anhalten: mysql -p -e „stop slave
auf den Master connecten: mysql -p -e „set global binlog_checksum=’NONE‘; SHOW MASTER STATUS;“ ausführen.

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000138 | 521505   |              |                  |
+------------------+----------+--------------+------------------+

Datenbank auf dem Master dumpen, auf den Elfen kopieren. Auf dem Elfen die Datenbank wipen, den SQL Dump einspielen.

Auf dem Elfen : mysql -p -e „change master to MASTER_LOG_FILE=’mysql-bin.000138′, MASTER_LOG_POS=521505;start slave

Sollte wieder gehen. Ging nicht.. Neuer Fehler! Statt:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000136' a'

gabs jetzt :

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'test@masterserver:3306' - retry-time: 60  retries: 86400

Er zum Geier ist „TEST“ !?

Tja, keine Ahnung wie das passieren konnte, aber der „change master to …“ Befehl hatte den Replikationsusernamen durch „test“ ersetzt! Einfach so! Passwort war ok, Servername war ok, Username weg! Wie geil ist das denn ?!?!?

Also nochmal mit dem change master an den Elfen ran:

/usr/bin/mysql -p -e „stop slave;;CHANGE MASTER TO MASTER_USER=’myreplicationusername‘,MASTER_PASSWORD=’MeinPasswort‘;start slave

Da machste was mit als Admin … Ich wollte doch nur den Exim abdichten, nicht das Rad neu erfinden! Naja, jetzt gehts ja erstmal wieder 🙂 Und bevor noch einer fragt, nein, der Server hatte extern nur Port 25 zu bieten, deswegen ja auch das Update 😉