Nach Upgrade nach Fedora 42 Probleme mit der Datenbank MySQL, wegen Downgrading
Vorneweg, ich habe drei Stunden Troubleshooting gebraucht, also das Lösen des Problems liegen hinter mir. Ich habe mir einen Tag Pause gegönnt, denn es ist höchste Konzentration vonnöten. So etwas macht man nicht nebenbei.
Was ist Troubleshooting?
Troubleshooting umfasst die Fehlersuche und die Fehlerbehebung und ist ein systematischer Ansatz zur Problemlösung, der häufig verwendet wird, um Probleme in komplexen Maschinen, Elektronik, Computern und Softwaresystemen zu finden und zu eliminieren. Der erste Schritt bei den meisten Fehlerbehebungsmethoden ist das Sammeln von Informationen über das Problem, zum Beispiel ein unerwünschtes Verhalten oder das Fehlen einer erwarteten Funktionalität.
Quelle: https://www.computerweekly.com/de/definition/Fehlersuche-Troubleshooting
Ausgangssituation
Fedora 41 mit einer MySQL-Datenbank, die ich durch einen Tipp eines Anwender im Business-Netzwerk LinkedIn statt 8.4 hieß, sondern 9.2. Eine Version, die es wohl nicht so häufig gibt.
Upgrade am Donnerstag 30.10.2025 gemacht. Dabei hat das Programm, welches den Download in Fedora mit dem Befehl sudo dnf system-upgrade download –releasever=42 durchgeführt hat die bestehende Version 9.2 auf 8.4.7 heruntergestuft. Das hieß auch, die Version 9.2 wurde deinstalliert im Laufe des Upgrades.
Ich bin sehr mit der Kommandozeile, vertraut, daher bewege ich mich damit sehr viel darin. Für mich sind schwarz-weiße Kästen mit Schrift nichts ungewohntes. Eigentlich ist es auch der normale Alltag. Die bunten Icons sind eigentlich nur Fassade, die man verschönert hat.
Erstes Problem
Fedora sich geweigert den Server von MySQL zu starten.
Wenn ich hier von Server spreche, meine ich einen Dienst und nicht einen eigenständigen PC, der sich irgendwo in einem Rechenzentrum befindet. Was für Linux systemd ist, ist bei Windows services.msc.
Es lag eine Inkompatibilität des Ordnerverzeichnisses zu. Der Pfad von /var/lib/mysql war nicht der richtige zu meiner Version. Es wurde eine komplette Neuinitialisierung der Datenbankstruktur vorgenommen. Es wird eine neue Struktur für die neue, aber ältere Version, erstellt und die Berechtigung zu setzen. Hier wurde mit dem Befehl sudo mysqld –initialize –user=mysql –datadir=/var/lib/mysql gearbeitet. Root-Rechte kann man auch mit sudo kurzzeitig herstellen. Dazu braucht man nicht immer das root-Passwort (bzw. des Admin-Passwort – wenn man es auf MS Windows überträgt).
Was ist eine Neuinitialisierung?
Herstellung eines ganz bestimmten Anfangszustandes eines Computers, eines Programms, einer Prozedur oder eines Objekts. Bei Programmen und sonstigen Software-Einheiten alle Variablen vor der ersten Anwendung zu belegen, um einen korrekten Ablauf des Programms zu gewährleisten [Gebrauch: EDV]
Quelle: https://www.wortbedeutung.info/Initialisierung/
Da lief der Server endlich, aber der Client, das Programm, die Datenbank konnte sich nicht verbinden. Es kam beim Verbindungsversuch immer die Fehlermeldung: „ERROR 2002 Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock“
Auch hier lag ein Problem mit dem Pfad vor. Der Server suchte die Datei mysql.sock auf /var/run/mysqld, aber der Client war anders eingestellt.
Den eigentlichen Standort der Socket-Datei festzustellen. Das habe ich hier mit diesem langen Befehl sudo find / -type f -iname „mysql.sock“ 2>/dev/null“ 2>/dev/null gemacht. Suche im „Admin-Verzeichnis“ nur nach Dateien mit der Bezeichnung mysql.sock – ignoriere die Groß- und Kleinschreibung. Damit man keine Fehlermeldungen sieht, die oftmals nur verunsichern und auch ablenken, sondern nur das reine Ergebnis, werden Fehlermeldungen in Nirwana geschickt. Das macht man mit in Linux mit .
MySQL hat auch eine Konfigurationsdatei, wo die ganzen Pfade gespeichert werden. Die Datei heißt my.cnf und befindet sich zumindest in Fedora im Verzeichnis /etc/. Es wurde der korrekte Pfad /var/run/mysqld/mysql.sock in den Sektionen [mysqld] und [client]. Die Sektion [client] musste ich manuell hinzufügen.
Nano-Krieg und die Passwort-Falle
Um den Befehl mysqld_safe –skip-grant-tables funktioniert in der Kommandozeile nicht, weil mysqld_safe wurde nicht erkannt, wahrscheinlich, weil es nicht mehr gibt.
Manche Anweisungen im Internet sind nicht immer auf dem neuesten Stand. Mag sein, dass mein Blogeintrag in fünf Jahren auch anders funktioniert, weil sich doch etwas ändert hat. Daher beschreibe ich auch nur den Ist-Zustand von 30.10.2025. Nostaltiger werden diesen Eintrag in fünf Jahren für sehr interessant halten.
Also bin ich dann schließlich mit sudo systemctl edit mysqld in eine temporärer Konfigurationsdatei gegangen, wo sich der nano editor öffnete.
Es sollten drei Zeilen eingefügt werden:
[Service]
ExecStart=
ExecStart=/usr/bin/mysqld –skip-grant-tables
Das misslang, was mir bei den ersten Male nicht bewusst war. Es kam nach dem Speichern mit STRG + O und STRG + X in gelber Schrift „new contents are empty, not writing file„, aber das habe ich nur für eine Information gehalten. Es gibt viele gelbe Zeilen, als Meldungen, die man sich durchliest, aber keine Bedeutung schenkt. Diese Mitteilung hätte ich ernst nehmen müssen, denn Nano hat nichts gespeichert.
Daher kam dann der lange Befehl zum Einsatz. echo -e „[Service]\nExecStart=\nExecStart=/usr/bin/mysqld –skip-grant-tables“ | sudo tee /etc/systemd/system/mysqld.service.d/override.conf
Jetzt wurden endlich die Informationen ordnungsgemäß gespeichert.
Danach konnte ich mich endlich mit mysql -u root in die Datenbank als root einloggen.
Es gab dann noch einige Hürden zu überwinden, aber zum Schluss konnte ich das Root-Passwort setzen. Einmal testen, funktioniert. Dann musste ich mich als neuen Benutzer für diese Datenbank wieder hinzufügen. Jetzt funktioniert die Datenbank wieder.
Auch das grafische Programm DBeaver CE kann sich wieder mit der Datenbank verbinden. DBeaver ist eine grafische Oberfläche – nicht nur für MySQL – wo man bequem auf Datenbankmanagementsysteme, so heißen sie korrekt, zugreifen kann.
Meinen Kampf habe ich hier unten mit der einzelnen Befehlen veröffentlicht. Die Befehle, wo ein Passwort sichtbar sind, habe ich nicht veröffentlicht.
Wie habe ich die Befehle dokumentiert?
Ich habe das nicht gemacht. Das macht die Kommandozeile von sich aus. Dazu gibt es den Befehl history. Für die PowerShell / CMD in Windows gibt es ähnliche Befehle. Dann habe ich alles hier her kopiert.
Mein Kampf als Befehle
sudo systemctl status mysqld
813 sudo systemctl start mysqld
814 sudo systemctl status mongod
815 mysql –version
816 sudo journalctl -xeu mysqld.service
817 sudo journalctl -xeu mysqld.service > meldungen.txt
818 gedit meldungen.txt
819 sudo systemctl stop mysqld
820 sudo systemctl status mongod
821 sudo systemctl status mysqld
822 sudo mv /var/lib/mysql /var/lib/mysql_old_9.2
823 clear
824 sudo mysqld –initialize –user=mysql –datadir=/var/lib/mysql
825 sudo chown -R mysql:mysql /var/lib/mysql
826 sudo systemctl start mysqld
827 sudo systemctl status mysqld
828 sudo systemctl enable mysqld
829 sudo systemctl status mysqld
830 clear
831 mysql -u sven -p
832 mysql_secure_installation
833 sudo systemctl status mysqld
834 sudo mysql_secure_installation
835 mysql -u root -p
836 sudo systemctl stop mysqld
837 sudo systemctl status mysqld
838 sudo mysqld_safe –skip-grant-tables &
839 mysql -u root
840 sudo mysqld_safe –skip-grant-tables
841 sudo systemctl edit mysqld
842 sudo systemctl daemon-reload
843 sudo systemctl start mysqld
844 sudo systemctl status mysqld
845 mysql -u root
846 rpm -qa | grep mysql-server
847 rpm -qa | grep mysql
848 sudo restorecon -R /var/lib/mysql
849 sudo systemctl restart mysqld
850 sudo systemctl stop mysqld
851 sudo systemctl edit mysqld
852 systemctl daemon-reload
853 sudo systemctl daemon-reload
854 sudo systemctl start mysqld
855 mysql -u root
856 cd /etc/
857 ls
858 cd my.cnf.d/
859 ls
860 cd ..
861 cat my.cnf
Der Pfad stimmte nicht überein und SELinux Berechtigungen mussten neu gesetzt werden.
862 cd
863 sudo chcon -t mysqld_var_run_t /var/lib/mysql/mysql.sock
864 ls -l /run/mysqld/mysql
865 sudo ls -l /run/mysqld/mysql
866 sudo ls -l /run/mysqld
867 sudo nano /etc/my.cnf
868 sudo mkdir -p /var/run/mysqld
869 sudo chown mysql:mysql /var/run/mysqld
870 sudo systemctl daemon-reload
871 sudo systemctl restart mysqld
872 sudo systemctl status mysql.service
873 sudo systemctl status mysqld
874 sudo systemctl start mysqld
875 sudo mkdir -p /var/run/mysqld
876 sudo chown mysql:mysql /var/run/mysqld
877 sudo restorecon -R /var/run/mysqld
878 sudo systemctl restart mysqld
879 journalctl -xeu mysqld.service > meldungen2.txt
880 gedit meldungen2.txt
881 cat /etc/my.cnf
882 cat /var/log/mysqld.log
883 sudo cat /var/log/mysqld.log
884 sudo cat /var/log/mysqld.log > mysql_log.txt
885 gedit mysql_log.txt
886 find / -type -f -iname my.cnf
887 find / -type f -iname my.cnf
888 sudo find / -type f -iname my.cnf
889 sudo mkdir -p /var/run/mysql
890 sudo chown mysql:mysql /var/run/mysql
891 sudo restorecon -R /var/run/mysql
892 sudo systemctl restart mysqld && sudo systemctl status mysqld
893 mysql -u root
894 cat /etc/my.cnf
895 mysql -u root –socket=/var/lib/mysql/mysql.sock
896 cd /var/lib/mysql
897 sudo cd /var/lib/mysql
898 sudo cd /var/lib
899 sudo cd /var/
900 pwd
901 sudo cd var/
902 cd /var/
903 cd lib
904 ls
905 cd mysql
906 sudo cd mysql
907 su
908 cd
909 find / -type f -iname „.sock„
910 sudo find / -type f -iname „mysql.sock“ 2>/dev/null
911 sudo nano /etc/my.cnf
912 sudo rm -rf /var/run/mysql
913 sudo mkdir -p /run/mysqld
914 sudo chown mysql:mysql /run/mysqld
915 sudo restorecon -R /run/mysqld
916 sudo systemctl restart mysqld
917 sudo systemctl status mysqld
918 mysql -u root
919 sudo find / -type f -iname „mysql.sock“ 2>/dev/null
920 sudo mkdir -p /run/mysqld/mysql_sock_old
921 sudo ls /run/mysqld/
922 cp /run/mysqld/mysql.sock.lock /run/mysqld/mysql_sock_old
923 sudo cp /run/mysqld/mysql.sock.lock /run/mysqld/mysql_sock_old
924 sudo ls /run/mysqld/
925 cd /run/mysqld/
926 ls
927 ls mysql_sock_old/
928 mv mysql.sock.lock mysql.sock
929 sudo mv mysql.sock.lock mysql.sock
930 cd
931 mysql -u root
932 cd /run/mysqld/
933 ls
934 cat mysql.sock
935 sudo cat mysql.sock
936 sudo cat mysqld.pid
937 sudo mv mysql.sock mysql.sock.lock
938 ls
939 cd
940 sudo systemctl stop mysqld
941 sudo rm -f /run/mysqld/sock
942 cd /run/mysqld/
943 ls
944 sudo rm -rf mysql_sock_old/
945 cd
946 sudo systemctl start mysqld
947 sudo tail -n 50 /var/log/mysqld.log > mysql_log_letzte_50.txt
948 gedit mysql_log_letzte_50.txt
949 mysql -u root –socket=/var/run/mysqld/mysql.sock
950 sudo systemctl stop mysqld
951 sudo /usr/bin/mysqld_safe –skip-grant-tables &
952 sudo systemctl edit mysqld
953 sudo systemctl daemon-reload && sudo systemctl restart mysqld && sudo systemctl status mysqld
954 mysql -u root –socket=/run/mysqld/mysql.sock
955 mysql -u root -p
956 mysql -u root
957 mysql -u sven
958 mysql -u sven -p
959 sudo nano /etc/my.cnf
960 mysql -u root
961 mysql
962 sudo systemctl edit mysqld
963 cd /etc/systemd/system/
964 ls
965 clear && ls
966 pwd
967 cd
968 history | grep find
969 sudo find / -type f -iname „mysqld.ser“ 2>/dev/null
970 sudo nano /etc/my.cnf
971 sudo systemctl edit mysqld
972 sudo mkdir -p /etc/systemd/system/mysqld.service.d
973 echo -e „[Service]\nExecStart=\nExecStart=/usr/bin/mysqld –skip-grant-tables“ | sudo tee /etc/systemd/system/mysqld.service.d/override.conf
974 cat /etc/systemd/system/mysqld.service.d/override.conf
975 sudo systemctl daemon-reload && sudo systemctl restart mysqld && sudo systemctl status mysqld
976 mysql -u root –socket=/var/run/mysqld/mysql.sock
Hier werden Passwörter gezeigt, die ich nicht veröffentliche.
980 mysql -u root –socket=/var/run/mysqld/mysql.sock
981 sudo rm /etc/systemd/system/mysqld.service.d/override.conf && sudo systemctl daemon-reload && sudo systemctl restart mysqld
982 mysql -u root –socket=/var/run/mysqld/mysql.sock
983 sudo systemctl restart mysqld