systemd bug: systemd-tmpfiles-setup.service fails with unknown user “systemd-network”

I had a strange error after updating “systemd” on one of my Opensuse server systems from version 228.41.1 to version 228.44.1. This update seems harmless, but it is not. With it substantial changes appear in the file /usr/lib/tmpfiles.d/systemd.conf. Especially the lines:

d /run/systemd/netif 0755 systemd-network systemd-network -
d /run/systemd/netif/links 0755 systemd-network systemd-network -
d /run/systemd/netif/leases 0755 systemd-network systemd-network -
</p>

In my case this lead to trouble – service “systemd-tmpfiles-setup.service” started to fail :

# systemctl status -l systemd-tmpfiles-setup
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
   Active: failed (Result: exit-code) .....
...
...
Mar 12 11:33:32 myserv systemd-tmpfiles[509]: [/usr/lib/tmpfiles.d/systemd.conf:19] Unknown user 'systemd-network'.

I checked whether user “systemd-network” existed with YaST. Yes, it was there – with all its default details.
However the command

getent passwd systemd-network

did not give me anything!

It took me a bit to find out what had happened. On this server I had once experimented with NIS, NISplus. The “/etc/passwd”-file still contained a line

+::::::

The “/etc/group”-file had a corresponding “+:::”. However, no active NIS server is any longer defined. Should not matter as long as the file have a correct format, i.e. as long as the NIS-lines are placed at the bottom of the files …

But:
At some point in time (?) systemd had created the user “systemd-network” and a corresponding group. Unfortunately, both entries were dumbly added at the end of the files “/etc/passwd” and “/etc/group” – i.e. after the already existing NIS-lines.

systemd-timesync:x:478:478:systemd Time Synchronization:/:/sbin/nologin
+::::::
systemd-network:x:475:475:systemd Network Management:/:/sbin/nologin

Not funny! Because, this in turn became the cause for the empty “getent”-answer!

However, it seems that systemd now uses “getent” to check the existence of some special systemd-users like “systemd-network” as a requirement for starting certain services. Which then leads to errors …

Summary
“systemd” seems to add new user- and group-entries at the bottom of the files “/etc/passwd” and “/etc/group” – without checking for NIS lines. Or it at least did at some point in the past. This may prevent the start of some initial services for which the existence of user or group entries are checked.

So, if you run across a similar problem check your “passwd” and “group” files for wrong entries at the end of the file! Move the NIS lines to the very bottom of the files. Afterward “getent” will work again for all user entries – and your failed services hopefully will start again.

Note: If you still get errors for “unknown systemd-users” you have to check whether entries for all the required users really exist in “/etc/passwd”.

P.S.: The stupid thing on Opensuse is that YaST shows you the required users with passwd-entries below a NIS line as existing, whereas “getent” does not.

Upgrade auf Opensuse Leap 42.3 – Nvidia Problem

Ende Januar sind die letzten Nachzügler in meinem Umfeld von Opensuse Leap 42.2. auf Leap 42.3 upgegradet worden. Bei zwei Desktop-Systemen ist mir dabei noch ein unangenehmer Nebeneffekt des proprietären Nvidia-Treibers aufgefallen.

Auf dem ursprünglichen “Opensuse Leap 42.2”-System war zum damals aktuellsten Kernel 4.4.104 der Nvidia-Treiber in der Version 384.98 installiert worden – aus der von Nvidia heruntergeladenen Datei “NVIDIA-Linux-x86_64-384.98.run”.

Nach dem Upgrade mit zypper etc. (s. hierzu https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/) hatte ich erwartet, dass das neue Leap 42.3-System maximal in den Konsolenmodus hochfahren und die grafische Oberfläche nicht anzeigen würde.

(Den Konsolenmodus erreicht man auch unter systemd üblicherweise durch Eingabe von “init 3″ auf der Kommandozeile oder durch Angabe des Kernelparameters ” 3″ beim Booten. Auf das Starten des grafischen Targets wird dann verzichtet.)

Eine Neukompilation des Treibers ist nach Kerneländerungen ja Standard – und unter Leap 42.3 war die Kernel-Version 4.4.114 gegeben. Zudem wusste ich von früheren Upgrade-Versuchen bereits: Beim Upgrade wird aus unerfindlichen Gründen das Paket “drm-kmp-default” für “back-ported drm kernel modules” installiert, welches aber nicht mit den ansonsten installierten “drm”-Bibliotheken und auch nicht zusammen mit den aktualisierten Kernel-Versionen (> 4.4.79) funktioniert.

Man kam denn auch nur in eine Art Konsolenmodus (unter Opensuse auf tty1). Leider flackerte das angezeigte Terminal aber unaufhörlich; es war mir dabei nicht möglich, normale Tastatureingaben zu machen. Das System befand sich in einem Zwischenzustand zwischen “init 3” und dem vollen grafischen Target (“init 5”) von systemd. Bzw.: Wechselte laufend zwischen beiden Modi hin und her. Äußerst übel – und sicher auch nicht gerade förderlich für die HW des Schirms! Den schaltete ich dann erstmal zur Sicherheit ab.

Ich konnte das Problem nur beheben, indem ich mich von einem anderen System aus per SSH als root anmeldete und dann (remote) am Prompt “init 3” eingab. Das führte dann auch am Schirm des betroffenen Systems zu einem benutzbaren Zustand auf der Konsole.

Die nächsten Schritte bestanden dann im Aufruf von “yast”, um erstens das Paket “drm-kmp-default” zu deinstallieren und dann eine Neuinstallation des Nvidia-Treibers vorzunehmen. Was schließlich zu einem reibungslosen Systemstart in den grafischen Modus führte.

Ich habe nicht getestet, ob alternativ ein Neustart unter Auswahl des “Wiederherstellungsmodus” über das Submenu von Grub2 geholfen hätte. Ich vermute das, weiß es aber nicht.

Eine Variante, die man bei Auftreten des “Flacker-Problems” auch ausprobieren sollte, ist: Mehrfach mit “Ctrl-Alt-Delete” einen Neustart erzwingen. Dann den Grub-Editor vor dem Booten (Taste “e”) nutzen und an die Startzeile den Kernelparameter ” 3″ anhängen.

Also liebe Opensuse- und Nvidia-Fans:
Ihr seid gewarnt! Vielleicht ist es eine gute Idee, vor dem Upgrade den proprietären Nvidia-Treiber zuerst zu deinstallieren (NVIDIA-Linux-x86-384.98.run –uninstall) und sich auf den “nv”-Treiber zurückzuziehen.

Update zu Opensuse 42.3 – kleine Probleme mit nvidia und libvirt/kvm

Das aktuelle Drama um Meltdown und Spectre verlangt auch von Linux-Usern starke Nerven. Bei Opensuse steht zudem das Auslaufen des Support-Zeitraums für Opensuse Leap 42.2 an. Es lohnt sich also, hier auch noch ein Upgrade betroffener Systeme auf Opensuse Leap 42.3 vorzunehmen. In der Reihenfolge

  1. Anwendung aktueller Kernel-Patches (man suche z.B. unter YaST > Software Management” mit dem Begriff “kernel” nach entsprechenden RPM-Paketen und deren Updates) sowie von Intel- bzw. AMD-Microcode-Patches (Pakete “ucode-intel”, “ucode-intel-blob” bzw. “ucode-amd”) unter Opensuse Leap 42.2.
  2. Bei Einsatz von qemu, kvm, libvirt: Update entsprechender Pakete unter Leap 42.2.
  3. Upgrade auf Opensuse Leap 42.3 (z.B. gem. der Anleitung unter https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/)
  4. Soweit dann noch nötig: Anwendung aktueller Kernel-Patches, von Intel- bzw. AMD-Microcode-Patches und Updates von qemu/kvm/libvirt-Paketen unter Leap 42.3
  5. [Für Mutige (und Sicherheitsbewusste): Upgrade auf ein aktuelles Kernel-Paket zur Version 4.14 aus dem “kernel”-Repository “http://download.opensuse.org/repositories/Kernel:/stable/standard/”.]

Das klappt eigentlich ganz gut. Bei zwei Systemen bin ich dabei im Zuge des Standard-Upgrades aber auf zwei kleinere Problemchen mit “kvm/qemu” und dem proprietären “Nvidia”-Treiber gestoßen.

Nvidia-Problem => Deinstallation des Pakets “drm-kmp-default”

Im Zuge der Installation des proprietären Nvidia-Treibers (z.B. über das Installations-File “NVIDIA-Linux-x86_64-384.98.run”), den man sich von der Nvidia-Web-Site laden kann, klappt zwar die Kompilation des Treibers, nicht aber das Laden des Moduls “nvidia-drm.ko”. Es kommt eine entsprechende Meldung zum Fehlschlag der Nvidia-Installation. Ursache ist ein Paket “drm-kmp-default”, das aus mir nicht nachvollziehbaren Gründen installiert wird, aber in seiner Version nicht zum aktualisierten Default-Kernel (z.Z. 4.4.104-39.1) des Leap 42.3-Systems passt. Hier hilft es, das Paket “drm-kmp-default” zu deinstallieren. Das “drm”-Modul wird dennoch geladen und vom Modul “drm-nvidia” auch korrekt verwendet.

qemu/kvm-Problem: Korrekten Eintrag zu “namespaces” in der Datei qemu.conf vornehmen

Nach dem Upgrade auf Leap 42.3 und Aktualisierung aller Virtualisierungspakete ließen sich leider keine KVM-Gastsysteme mehr starten. Ich erhielt ganz unabhängig von der Art des Gastes und dessen Betriebssystem eine Meldung der Art:

Error starting domain: internal error: child reported: Kernel does not provide mount namespace: Permission denied

Ursache ist ein fehlender Eintrag

#namespaces = [ “mount” ]
namespaces = []

(bzw. ein unwirksamer Default-Eintrag (namespaces = [ “mount” ])) in der Datei “/etc/libvirt/qemu.conf”.
Ich tippe darauf, dass dieses Problem durch Rückportierungen bestimmter neuer Kernel-Features auf die relativ veraltete 4.4-Version von Leap 42.3 verursacht wurde. Im Standard-4.4-Kernel brauchte man den Eintrag in der vorliegenden Form nämlich nicht. Auf die Lösung dieses Problems bin ich nicht selbst gekommen; s. zu diesem Thema die unten angegebenen Links.

Viel Spaß weiterhin mit Opensuse – trotz des aktuellen Security Super-GAUs. Das beste Gegenmittel gegen Spectre ist – neben laufenden System-Updates – maximale Vorsicht beim Öffnen jeglicher externer Quellen, das Verifizieren von Update-Quellen für System- und Anwendungsdateien und das Verifizieren von Web-Sites im Internet über https-Verbindungen, das Kontrollieren der Hash-Summen für alle Updates sowie der Einsatz von “Noscript
“-Plugins in euren Browsern. Soweit ich das verstehe, erfordert ein Ausnutzen der Spectre-Schwachstelle in den aktuellen Prozessoren das Ausführen malignen Codes. Ein Einfangen von Schadcode muss man vermeiden – diese Binsenwahrheit gilt und erfordert nunmehr weiter erhöhte Wachsamkeit – im besonderen beim Browsen im Internet.

Vielleicht denken einige Unternehmen und Webseiten-Programmierer nun auch wieder ein wenig mehr darüber nach, ob und wann Javascript für den Betrieb einer öffentlichen Web-Seite überhaupt erforderlich ist. Auf vielen Seiten erfolgt der Einsatz oftmals weniger aus funktionalen Gründen als vielmehr deshalb, damit das Nutzerverhalten aus kommerziellen Gründen getrackt werden kann …..

Links

https://forums.opensuse.org/showthread.php/527697-Can-t-load-nvidia-drm-ko-after-update
https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
https://www.redhat.com/archives/libvirt-users/2017-March/msg00033.html
https://www.redhat.com/archives/libvirt-users/2017-March/msg00035.html