Single User Mode mit systemd

Deutsch (German) Installation/Administration
#1

Seit dem Update auf Leap meldet mein System bei jedem Boot:


2018-01-28T13:50:49.948956+01:00 xenon systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway.
2018-01-28T13:50:49.948998+01:00 xenon systemd[1]: var-run.mount: Directory /var/run to mount over is not empty, mounting anyway.
2018-01-28T13:50:49.949018+01:00 xenon systemd[1]: var-lock.mount: Directory /var/lock to mount over is not empty, mounting anyway.

Das scheint zwar keine nachteiligen Folgen zu haben, aber ich möchte doch gern wissen, was da durch den Mount verdeckt wird, und es gg. wegräumen.
Dazu müsste ich die Filesysteme von /var/run (tmpfs), /var/lock (ebenfalls tmpfs) und /var (ext4) einmal aushängen, was natürlich im laufenden Betrieb nicht geht.
Früher mit sysvinit hätte ich dafür mit

telinit S

in den Single User Mode gewechselt.
Wie mache ich das mit systemd?

#2

Genauso.
Oder “systemctl isolate rescue.target”.

Obwohl du vermutlich auch im rescue.target /var nicht unmounten kannst…

Alternativen: von irgendeiner LiveCD booten, oder (was ich persönlich machen würde), z.B. “init=/bin/sh” oder “rd.break” zu den Bootoptionen hinzufügen. Dann landest du in einem minimalen Textmodussystem, wo kein Systemdienst läuft und nichts gemountet wurde…

(bei “init=/bin/sh” solltest du normal auf / zugreifen können, bei “rd.break” ist / noch die initrd und das eigentliche / ist unter /sysroot/ ro gemountet, “mount /sysroot -o remount,rw” erlaubt Schreibzugriff).

#3

Danke, das hat gut funktioniert.
/var konnte ich in der Tat nicht aushängen.
Auch /var/run nicht - laut lsof hatte systemd darin trotz single user mode noch einige Dateien offen.
Aber /var/lock ging.
Im Mountpoint /var/lock des /var-Filesystems fanden sich dann zwei leere Verzeichnisse /var/lock/dmraid und /var/lock/subsys, die sich problemlos entfernen ließen.
Erste Meldung weg.

Das hat auch gut geklappt. Ich habe die Variante “init=/bin/sh” gewählt. (Auch da ist das Root-Filesystem übrigens noch ro gemountet.)
Damit fand ich dann unter dem Mountpoint /var ein Verzeichnis /var/lock mit einer Datei /var/lock/asound.state.lock und einem leeren Unterverzeichnis /var/lock/lvm.
Auch diese ließen sich problemlos entfernen.
Zweite Meldung weg.

Schwierigkeiten bereitet mir jetzt noch der Mountpoint /var/run im /var-Filesystem.
Nach “systemctl isolate rescue.target” kann ich wie gesagt /var/run wegen systemd nicht aushängen.
Mit der Rescue Shell (init=/bin/sh) kann ich aber /var nicht einhängen, weil LVM noch nicht läuft:

# mount /var
mount: special device /dev/RAID/var does not exist

Hast Du einen Tipp, wie ich die Zwischenstufe “/var gemountet, /var/run nicht” erreichen könnte?

#4

Kann sein, ist ne Weile her dass ich das das letzte Mal gemacht habe.
Ich denke aber dass das nur der Fall ist wenn die Bootoption “ro” gesetzt ist. Bei mir ist das nicht der Fall, aber das hängt vom System ab…

Schwierigkeiten bereitet mir jetzt noch der Mountpoint /var/run im /var-Filesystem.
Nach “systemctl isolate rescue.target” kann ich wie gesagt /var/run wegen systemd nicht aushängen.
Mit der Rescue Shell (init=/bin/sh) kann ich aber /var nicht einhängen, weil LVM noch nicht läuft:

# mount /var
mount: special device /dev/RAID/var does not exist

Hast Du einen Tipp, wie ich die Zwischenstufe “/var gemountet, /var/run nicht” erreichen könnte?

Tja, das LVM verkompliziert das etwas, und ich muss zugeben dass ich damit keine Erfahrungen habe.

/var/run/ ist aber im Prinzip nur ein Kompatibilitäts-Verweis auf /run/, dass als tmpfs gemountet ist (also nur im RAM vorhanden ist).
Das ist eigentlich gar nicht gemountet sondern nur ein Symlink (hier zumindest, mit reiserfs als Dateisystem).
Probier vielleicht mal den entsprechenden Eintrag in der fstab auszukommentieren (also ein ‘#’ voranstellen). Evtl. “mkinitrd” ausführen damit die Änderungen in die initrd übernommen werden.

#5

Bei mir sind /var/run und /run keine Symlinks, sondern Mount Points, an denen aber offenbar dasselbe tmpfs-Filesystem eingehängt ist - wahrscheinlich ein bind mount:

ts@xenon:~> findmnt /run
TARGET SOURCE FSTYPE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,nodev,mode=755
ts@xenon:~> findmnt /var/run
TARGET   SOURCE FSTYPE OPTIONS
/var/run tmpfs  tmpfs  rw,nosuid,nodev,mode=755
ts@xenon:~> ls -lid /run /var/run
8929 drwxr-xr-x 41 root root 1060 30. Jan 01:11 /run
8929 drwxr-xr-x 41 root root 1060 30. Jan 01:11 /var/run

Für keins von beiden gibt es einen Eintrag in /etc/fstab.
Laut Log-Eintrag scheint für /var/run eine systemd unit namens var-run.mount verantwortlich zu sein.
systemctl scheint dies zu bestätigen:

ts@xenon:~> systemctl status var-run.mount
● var-run.mount - Runtime Directory
   Loaded: loaded (/usr/lib/systemd/system/var-run.mount; static; vendor preset: disabled)
   Active: active (mounted) since So 2018-01-28 16:07:11 CET; 1 day 9h ago
    Where: /var/run
     What: tmpfs
  Process: 1106 ExecMount=/usr/bin/mount /run /var/run -t bind -o bind (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 512)

Kann ich diese Unit einfach mal disablen oder mache ich mir damit das System kaputt?

#6

Ok, sorry.
Bei mir ists ein Symlink:

wolfi@amiga:~/Desktop> ll /var/run
lrwxrwxrwx 1 root root 6  3. Nov 2014  /var/run -> ../run
wolfi@amiga:~/Desktop> findmnt /var/run
TARGET SOURCE FSTYPE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,nodev,mode=755

Kann aber durchaus ein “Überbleibsel” von älteren openSUSE Versionen sein. Dieses System ist das letzte Mal vor 15 Jahren neu installiert worden… :wink:

Für keins von beiden gibt es einen Eintrag in /etc/fstab.

Ok. Ich dachte du hast evtl. einen Subvolumen-Mount in fstab.
Hm. Funktioniert “systemctl stop var-run.mount” um es unzumounten?

Kann ich diese Unit einfach mal disablen oder mache ich mir damit das System kaputt?

Disablen wird wohl nicht gehen, weil es “static” ist.
Evtl. maskieren mit “systemctl mask var-run.mount”.

Oder einfach /usr/lib/systemd/system/var-run.mount “entfernen” (vorläufig woanders hinschieben), bzw. in /etc/systemd/system/ überschreiben:

sudo ln /dev/null /etc/systemd/system/var-run.mount

Am Ende dann halt die Datei wieder zurückschieben bzw. /etc/systemd/system/var-run.mount löschen.

Kann sein dass da dann wieder ein mkinitrd fällig ist um ein Mounten in der initrd zu verhindern.

Kaputtmachen sollte das nichts, /var/run/ ist dann halt auf der Festplatte (als Verzeichnis).
Im schlimmsten Fall würde das halt erst recht wieder neue Dateien anlegen, denke ich…

Ansonsten solltest du vermutlich das LVM von einer Live-CD mounten können.
Evtl. die Tumbleweed Rescue-CD (eine TW LiveCD mit XFCE), oder “GParted Live”:
https://gparted.org/livecd.php