WordPress 5.1.1 Multisites mit DB-Updateproblem

Nächste Warnung: Wer eine WordPress Multisite betreibt und von 5.0 auf 5.1.1 aktualisiert wird, der könnte ein Problem haben, ohne es zu wissen.

Datenbankupdate nicht ausgeführt

Die Fehler reichen von Logmeldungen wie dieser:

WordPress-Datenbank-Fehler Table ‚db466398.wp_blogmeta‘ doesn’t exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (6) ORDER BY meta_id ASC von include(‚wp-load.php‘), require_once(‚wp-config.php‘), require_once(‚wp-settings.php‘), require(‚wp-includes/ms-settings.php‘), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

bis hin zu 500er Fehlern, wenn man die Webseiten aufruft.

Das Problem wurde vor 4 Wochen bereits bekannt, konnte aber nicht zuverlässig reproduziert werden von den Devs, tritt aber so oft auf, daß es kein Zufall mehr ist, ich habs ja auch gehabt 😉

Lösung:

Einloggen in die Datenbank und das hier ausführen:

CREATE TABLE `wp_blogmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`blog_id` bigint(20) NOT NULL DEFAULT 0,
`meta_key` varchar(255) DEFAULT NULL,
`meta_value` longtext DEFAULT NULL,
PRIMARY KEY (`meta_id`),
KEY `meta_key` (`meta_key`),
KEY `blog_id` (`blog_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Dann hören die Meldungen im Errorlog des Apachen auf. Ob das auch den 500er behebt, kann ich nicht sagen, da er mir nicht passiert ist. Wer sich jetzt fragt wo ich die Struktur her habe, es gibt in WP eine Datei, in der die DB Schemata drinstehen, da bekommt man das her.

 

TPM2 Update zerlegt Fedorainstallation

Ihr habt einen TPM Chip im System ? Ihr setzt Fedora ein und habt deswegen den TPM Chip im Bios abgeschaltet ? Dann jetzt bloß nicht updaten!

Was passiert, wenn SEL auf TPM trifft

Ich fürchte ja, daß es dafür schon zu spät ist, aber sei es drum: NICHT UPDATEN! Sperrt das Paket in /etc/dnf/dnf.conf mit => „exclude=tpm2*“

Ok, das wird jetzt kompliziert, also langsam lesen.

Q: Wen betrifft das ?
A: Rechnerhardware mit einem TPM Chip auf dem Mainboard.

Q: Was ist TPM ?
A: Der Trusted Platform Modul – Chip signiert und prüft im Bootprozess, ob am System rumgespielt wurde und verweigert dann ggf. den Boot. Das macht in der Theorie den Rechner sicherer. Davon ab, kann man in dem Chip auch Digitale Signaturen und andere Kryptografische Informationen speichern und prüfen.

Q: Woher weiß ich, daß ich reinen TPM Chip habe?
A: Schaut ins Bios, der Chip wird da eine Option zum Ein- und Ausschalten haben.

Q: Was verursacht das Problem ?
A: Das Paket tpm2-abrmd-policies in der Version ( tpm2-abrmd-selinux-2.0.0-3.fc29 )  aktiviert beim Update wohl den TPM Chip und/oder setzt falsche SEL Policies im System, so daß der Rechner nicht mehr sauber bootet.

Q: Passiert das immer ?
A: Wissen wir noch nicht, ich war der einzige mit Fedora und TPM Chip.

Q: Sind spezielle Kernel im Spiel ?
A: Nein, wir haben 5.0.3, 4.19.23 und 4.20.5 ausprobiert => spielt keine Rolle.

Q: Wie wirkt sich das aus ?
A: Während des Bootprozesses stürzt der Kernel mit diversen Kernel-OOPS Meldungen ab. Mit Glück bootet er durch, bei mir war vor GDM Schluß mit lustig => System halt.
Wenn er durchbootet, dann bekommt man vom ABRT laufend Meldungen über Kernel-Abstürze, die automatisch behoben werden, teilweise 4x pro Minute.

Gegenmaßnahmen

als Root: systemctl stop tpm2-abrmd;systemctl disable tpm2-abrmd;

Dann rebooten und im BIOS den TPM Chip abschalten. Das hat bei mir dazu geführt, daß der vorherige Kernel 4.19.23 ( zu 4.20.5 ) sauber gestartet ist und im Bootprozess die SEL-Policies neu gesetzt wurden, im ganzen System, was ein Weilchen dauern kann. Danach lief jeder Kernel wieder normal, auch 5.0.3 .

Ein Bugreport wurde bei Red Hat abgesetzt. Ich wette, daß auch die TPM Maintainer vor einem Rätsel stehen, aber ich habe Augen- und Ohrenzeugen, da es mitten in unserer wöchentlichen LUG Sitzung passierte 😉

Update: Beitragstitel geändert, war zu reißerisch.