Fehler beim Mysql-Upgrade von 5.7.13 auf 5.7.14 unter Debian

Nach einem Upgrade eines Dantenbankservers von Mysql 5.7.13 auf 5.7.14 unter Debian Jessie (mit Verwendung des offiziellen Mysql-Repos) startete die Datenbank nicht mehr.

Im Logfile /var/log/syslog fand sich der Eintrag:
[ERROR] --initialize specified but the data directory has files in it. Aborting.

Ein ps aux | grep mysql zeigte zwei Prozesse: mysqld und ein startup-script „/bin/bash /usr/share/mysql/mysql-systemd-start pre"

Nach einem kill des startup-scriptes startete der Server. Eine Prüfung des Startup-Scriptes ergab, dass das Datenverzeichnis, welches bei diesem Server nicht im Default-Verzeichnis /var/lib/mysql lag, in Version 5.7.14 hardcodiert auf /var/lib/mysql gesetzt worden war, anstatt es aus der Konfigdatei auszulesen.

Wenn man mittels nano /usr/share/mysql/mysql-systemd-start die Zeile
MYSQLDATA=/var/lib/mysql
durch
MYSQLDATA=$(get_path datadir)
ersetzt, funktioniert der Server wieder wie gewohnt.

lsb_release gibt falsche Version aus

Nach dem Upgrade von Debian Wheezy auf Debian Jessie ergab eine Versionsprüfung mit lsb_release, dass es sich noch um Wheezy handeln sollte.

root@server:~# lsb_release -c
Codename:    wheezy

Beim Blick ins /etc-Verzeichnis fand ich eine config-Datei namens „lsb-release“. Dort waren noch alte Informationen hinterlegt:

root@server:~# cat /etc/lsb-release
DISTRIB_ID=Debian
DISTRIB_RELEASE=7.04
DISTRIB_CODENAME=wheezy
DISTRIB_DESCRIPTION=“Debian 7.04.1″

Nach dem Verschieben der Datei, war die Anzeige wieder korrekt:

root@server:~# mv /etc/lsb-release /etc/lsb-release.old
root@server:~# lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.3 (jessie)
Release:    8.3
Codename:    jessie

Anzahl der möglichen TCP-Verbindungen unter Debian erhöhen

Nachdem im Fehlerlog unseres Apache Servers die Meldung PHP Fatal error:  Uncaught exception 'RedisException' with message 'Connection closed' in [no active file]:0  auftauchte, musste die Anzahl der möglichen TCP-Verbindungen zur Ansteuerung des Redis-Servers erhöht werden.

Dazu waren verschiedene Anpassungen auf dem Webserver nötig.

Weiterlesen

Debian-Repository: ungültige Signatur

Beim Versuch eines Paketupdates per apt-get update im Terminal, erhielt ich folgende Fehlermeldung:

W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Repository wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: http://ftp.de.debian.org squeeze-updates Release: Die folgenden Signaturen waren ungültig: BADSIG AED4B06F473041FA Debian Archive Automatic Signing Key (6.0/squeeze)


W: Fehlschlag beim Holen von http://ftp.de.debian.org/debian/dists/squeeze-updates/Release


W: Einige Indexdateien konnten nicht heruntergeladen werden, sie wurden ignoriert oder alte an ihrer Stelle benutzt.

 

Abhilfe schaffte die Aktualisierung des keyrings mit folgendem Befehl:

apt-get install -t unstable debian-keyring debian-archive-keyring

Danach war die Aktualisierung wieder problemlos möglich. Manchmal kann es sinnvoll sein den keyring komplett zu entfernen und dann neu zu installieren. Das wäre mit folgenden Befehlen möglich:

dpkg --purge debian-archive-keyring
apt-get install debian-archive-keyring

 

 

Grub2 wiederherstellen / neu installieren

Gerade bei der Parallelinstallation mehrerer Systeme kann es leicht passieren, dass die Grub2-Installation zerstört wird und man sein System gar nicht mehr starten kann. Dieses Problem lässt sich jedoch sehr leicht lösen.

Wir installieren dazu aus der existierenden Installation auf der Festplatte Grub2 im MBR (Master Boot Record) der Festplatte neu.

Dazu booten wir von einer Ubuntu Live-CD, öffenen einen Terminal und geben folgende Befehle ein:

sudo -s
mkdir /system
mount /dev/sdaX /system
mount -o bind /dev /system/dev
mount -o bind /proc /system/proc
mount -o bind /sys /system/sys
chroot /system
update-grub
grub-install /dev/sda
exit

Dabei steht sda für die Bootfestplatte und sdaX für die Partition, auf der das System installiert ist (z.B. sda2). Welche Bezeichnungen / Partitionen zu verwenden sind kann man am leichtesten mit dem Tool gparted in der Systemadministration sehen. Mit gparted kann man auch verifizieren, ob für die Festplatte das benötigte Bootflag gesetzt ist.

Danach kann einfach neu gestartet werden. Das Bootmenü von Grub2 sollte dann wieder zur Verfügung stehen.