Category Archives: Leap 42.3

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

Posted on by

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

Posted on by

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.