Update: Fedora: Probleme mit hwdata und Asus Mainboards

Wie bereits vor zwei Tagen mitgeteilt, gibt es bei Fedora ein Problem mit dem Paket hwdata. Darin sind die PCI Ids der Geräte und Hersteller enthalten. Die Quelle der Daten wird bei Github gepflegt und damit betrifft es nicht nur Fedora, sondern alle Distributionen, die Ihre Daten von dort beziehen.

Die Datei oui.txt (Organisational Unit Ids) verursacht dies, offensichtlich sind dort Kennungen falsch eingetragen  oder verloren gegangen, so das Wechselmedien nicht sauber erkannt werden.

Kuriose an der Sache: Der eingesteckte USB Stick war für Root gemountet und nicht für den angemeldeten User.

Wie eine falsche OUI das auslösen kann, wird derzeit geprüft. Ich meine, da liegt ein ziemlich dicker Bug kurz vor seiner Entdeckung.

Update: Fedora 29 bootet nicht nach Upgrade

Kleines Follow-Up auf Warnung: Libreswan kann Ihren Bootprozess stören. Nachdem der Rechner gestern wieder lief, wie man im Beitrag auch nachlesen kann, dachte ich mir, probier das System mal mit allen wichtigen Sachen aus. Keine Fehler, die nicht zu erwarten gewesen wären. Mehrfaches Rebooten lief auch ohne Probleme durch, bis… ja, bis heute morgen.

„Der Morgen danach“ Ein Roman von B.Soffski

Der Reihe nach: Wir verließen unseren Helden, als er sich zur Nachtruhe zurückzog und den Rechner ausschaltete. Ja, ausschaltete. Die Art von Ausschalten, die Veränderungen an so einem Computer unmöglich macht. Die Art, wo das Wort stromlos drin vorkommt. Wir erinnern uns, daß der Computer vor diesem Ausschalten 3x neu gestartet wurde, nur um zu sehen, ob das mit dem Reboot auch wirklich klappt.

„Der Vormittag kam, sah und ihm klappten alle Regentropfen runter!“

Anders ausgedrückt, dieses Fedora 29 bootet schon wieder nicht. Es blieb „wieder“ beim NetworkManagereinsatz hängen 🙁 Das kann einfach nicht wahr sein, der hat doch gestern 3x neu gebootet, wie kann das sein?

„Karma is a Bitch“ ein Buch von L.Eben

Na gut. „Challenge accepted“ Eine gewisse Wut im Bauch ist ja nicht wirklich falsch bei so was, es spornt den Wüterich zu Leistungen an. Was machen? Das gleiche wie Gestern? Einen Versuch ist es wert, aber diesmal nicht in eine Rootshell booten, sondern in Runlevel 1 auch bekannt als Emergency.target von Systemd. Ja, also an sich eine gute Idee, NUR GEHTS NICHT! Was für eine verf******* S******* ist das denn?

Ok, also dem Kernel wieder erzählt „1 init=/bin/bash“, Netzwerk gestartet, dnf update und siehe, wieder ein Update. Aber total irrelevant. Das wars also nicht. /var/log/messages und systemd-journal gesichtet, nichts. Der Bootvorgang ging bis NetworkManager, aber das wars dann. Nicht mal mehr ein Crash, der etwas erklären könnte. Nada!

Auf Verdacht wurde dann „dnf reinstall NetworkManager* systemd*“ durchgeführt und “ systemd.debug-level=1 “ an die Kernelzeile angefügt, damit eine Rootshell bereitsteht, wenn man sie braucht ( ALT+F9 )  und was soll ich sagen, der Rechner bootete wieder in GDM. Was fürn Sch….. was ist das denn? Man kann nicht mehr in den Desktop einloggen ?!?!?! Root-Konsole mit ALT+F3 ( F9 hatte ich im Moment vergessen ), will mit Root einloggen und … sofortiger Logout. Und dann stehst Du da!

F9! Stimmt, einloggen nicht nötig, bin ja schon drin, also ab ins Logfile und ..

The Execution of /usr/lib/systemd/systemd resulted in „Permission denied!“

Äh.. den habe ich doch gerade erst frisch reinstalliert und wieso wird der beim Konsolenlogin aufgerufen?Wird er gar nicht, weil /bin/sh konnte man auch nicht mehr starten, gleicher Fehler „Permission denied!“  … und wenn Du jetzt F*** sagst, sag auch gleich SELINUX! NNNNNNEEEEEEEIIIIIINNNNNNNNNNNN!!!!!!!!!!!!! Nicht schon wieder SELinux! Ich fange an es zu hassen !

Einen Reboot mit dem Kernelparameter „enforcing=0“ später, fährt das System hoch, als wenn nie was gewesen wäre!

Aber was ist jetzt schon wieder mit SELinux und wieso hat das System denn überhaupt nach dem Upgrade gestartet? Das dürfte es doch gar nicht. Antwort: SELinux  ist halt auch nur eine von Menschen gemachte Software 😉

„Die Auflösung“ Ein Film von D.Itrich

Das Problem nahm seinen Lauf im Jahre 2018. Damals gab es ein Problem unter F27 mit den SEL Policies. Nach einem Update der SEL Policypacks startete das System nicht mehr, aber mit der Version davon lief es noch. Also trägt der Linuxer natürlich nach dem Downgrade den Updateinhibiter für das Paket ein und weil alles ein Jahr lang läuft, vergißt man es. Dann kommt das Systemupgrade auf F28 und es läuft auch mit der alten Policy, was blöd ist, weil man so beim Update auf F29 gar nicht mehr an diese Sperre denkt 🙂

Update sperre für die Pakete raus und „dnf update -y“ ausgeführt. Eine Ewigkeit später, weil gleich mal umgelabelt wird, dann die Probe: reboot !  Scheiße, geht!

Ob die Geschichte diesmal zu ende ist, oder ob morgen neuer Ärger auf mich wartet, könnt Ihr leider erst morgen lesen 😉

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.

 

Aus der Schmunzelecke von Bugzilla

Für Euch mal was zum Schmunzeln, das erlebt man auch nicht so oft, daß sich der Maintainer bei den Bugreportern dafür entschuldigt, in den Urlaub gefahren zu sein 😉

--- Comment #3 from Zdenek Dohnal <zdohnal@redhat.com> ---
Hi,

thank you for reporting the issue! I'm deeply sorry for inconvenience, I pushed
the update without cross checking if new net-snmp is already in the stable (I
wasn't able to add hplip to net-snmp update) and I went on vacation after that.
You can install previous version from koji for now
https://koji.fedoraproject.org/koji/buildinfo?buildID=1163784 .

Der Fall stellt sich so dar:

Der Maintainer von hplip, hat als Abhängigkeit net-snmp drin und haut sein Update ins Stable Repo, ohne zu checken, ob den auch die Version von net-snmp im Stable ist, die er braucht. Wars nicht, also hat DNF zu Recht rumgeheult, daß es nicht updaten kann, weil gibt es nicht ja nicht im Repo, was das Paket so braucht. Das kommt übrigens öfters vor, als man denkt. Sind halt alles nur Menschen 😀 Aber die Entschuldigung im Bugtracker ist ein Unikum 😀

Falls Euch das auch mal unterkommen sollte, ich hab die neue Version von net-snmp dann im UPDATES-TESTING Repo von Fedora vorgefunden und ein : dnf –enablerepo=updates-testing update net-snmp* hats dann gelöst. Da müßt Ihr dann natürlich die Euch fehlende Abhängigkeit benutzen, nicht net-snmp 😉

selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.