system failed to start due to systemd upgrade!

[charlyheinz]

Unglaublich:
Es steht und fällt anscheinend wirklich alles mit dem fstab - Eintrag bezüglich fstemp.

An einem weiteren System habe ich diesen Eintrag in der fstab:

tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

auskommentiert und anschließend ein DU durchgeführt- voila, alles läuft.

Code Select Expand

apt policy systemd
systemd:
  Installiert:           256~rc3-5
  Installationskandidat: 256~rc3-5


Falls jemandem dazu noch irgendetwas einfällt z.B Notwendigkeit des Eintrags und zukünftiger Pakete- Abhängigkeiten oder Ähnlichem dann doch bitte einen Kommentar hinterlassen.
Ansonsten ist das doch die schnellste Lösung, oder?

[hendrikL]

nun.  rm -f /etc/<foo>

[scholle1]

Zusätzliche Erklärung zu den Ladepfaden von systemd.

Siehe man systemd.unit und siduction PDF-Handbuch ab Seite 298 "7.11.1 Ladepfad der Unit-Dateien".
Dateien in oben aufgeführten Verzeichnissen überschreiben gleichnamige in darunter aufgeführten.

man-page:
Ladepfad beim Betrieb im Systemmodus (Auszug der uns betreffenden Verzeichnisse)
- /etc/systemd/system        System-Units, die vom Administrator erstellt bzw. geändert wurden
- /usr/lib/systemd/system    System-Units, die durch den Paketverwalter der Distribution
                             installiert wurden. In der man-page steht nur /lib, es ist aber ein
                             Link auf /usr/lib (usr merge)

Ladepfad bei der Ausführung im Benutzermodus
- /etc/systemd/user                 Benutzer-Units, die vom Administrator erstellt wurden
- $XDG_DATA_HOME/systemd/user       Units von Paketen, die im Home-Verzeichnis installiert wurden
  $HOME/.local/share/systemd/user     ($XDG_DATA_HOME falls gesetzt, andernfalls ~/.local/share)
- $XDG_DATA_DIRS/systemd/user       Zusätzliche Datenverzeichnisse, wie diese durch die
  /usr/local/share/systemd/user       XDG-Basisverzeichnis-Spezifikation festgelegt werden
  /usr/share/systemd/user             ($XDG_DATA_DIRS falls gesetzt, andernfalls
                                      /usr/local/share und /usr/share)

Die Unitdatei tmp.mount war bereits in systemd-256~rc2-1 am falschen Ort, nämlich im Benutzermodus
Verzeichnis /usr/share/systemd ohne angehängtes /user Verzeichnis. Damit die ganze Verrenkung
funktionierte, war der Link darauf im Systemmodus Verzeichnis /etc/systemd/system. Dann hat jemand
den ersten Fehler bemerkt und die Unit in systemd-256~rc3-5 nach /usr/lib/systemd/system verschoben,
ohne jedoch den Link in /etc zu bemerken.

Wenn wir Änderungen an Units vornehmen sind wir als Administratoren unterwegs und nicht als Paketbetreuer.
Deshalb gehören unsere Änderungen immer unter /etc, niemals unter /usr. Das hat auch den Vorteil, dass
unsere Änderungen in der Regel nicht durch Updates oder Upgrades überschrieben werden.
Sinnvoller Weise mit systemctl edit ..., systemctl mask oder systemctl revert zu handhaben.
Steht auch im Handbuch unter "7.11.5 Werkzeuge".

Bitte die Ausführungen nicht als Besserwisserei verstehen. Ich möchte nur die Verwirrung um die tmp.mount Unit,
die Link darauf und an welchem Ort wir das am besten reparieren etwas aufhellen.

[burrowsdav]

Thanks everyone for the efforts with confirming and diagnosing this problem.

The Debian maintainer has included a patch to remove the symlink /etc/systemd/system/tmp.mount in the post install script which should be included in the next release.  I noticed they have missed this one: /etc/systemd/system/local-fs.target.wants/tmp.mount but it doesn't seem to cause as much of an issue.

Patch can be found here for those curious:
https://salsa.debian.org/systemd-team/systemd/-/commit/a5ff99119a4b2ffc602d0fd97babeff1b5c23f69

[mdmarmer]

von edlin:

Ich kann nur für mich sprechen, aber ich habe gerade aufgeräumt und mein System bootet ohne Probleme.
Was habe ich zuletzt gemacht?

    apt full-upgrade
    Den symlink unterhalb von /etc gelöscht: rm -f /etc/systemd/system/tmp.mount
    Den Eintrag unterhalb /usr/share gelöscht: rm -f /usr/share/systemd/tmp.mount
    Den Eintrag vom tmpfs in der /etc/fstab auskommentiert.
System bootet  -- kein problem
funktionierte perfekt auf meinem Lenovo Ideapad i3 Laptop

from edlin post
I can only speak for myself, but I just cleaned up and my system boots without any problems.
What did I do last?
apt full-upgrade
Deleted the symlink below /etc: rm -f /etc/systemd/system/tmp.mount
Deleted the entry below /usr/share: rm -f /usr/share/systemd/tmp.mount
Commented out the tmpfs entry in /etc/fstab.
System boots -- no problem

worked perfectly on my Lenovo Ideapad i3 laptop

[ayla]

Code Select Expand

apt-cache policy systemd
systemd:
  Installiert:           256~rc3-6
  Installationskandidat: 256~rc3-6
  Versionstabelle:
*** 256~rc3-6 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

Link unter /etc/systemd/system beim du automatisch entfernt.

[NochEinNeuer]

von edlin:

Ich kann nur für mich sprechen, aber ich habe gerade aufgeräumt und mein System bootet ohne Probleme.
Was habe ich zuletzt gemacht?

    apt full-upgrade
    Den symlink unterhalb von /etc gelöscht: rm -f /etc/systemd/system/tmp.mount
    Den Eintrag unterhalb /usr/share gelöscht: rm -f /usr/share/systemd/tmp.mount
    Den Eintrag vom tmpfs in der /etc/fstab auskommentiert.
System bootet  -- kein problem
funktionierte perfekt auf meinem Lenovo Ideapad i3 Laptop

So hab ich das gestern ebenfalls gemacht und alles funktioniert soweit ich es feststellen kann unauffällig.

[Taliesin]

My sincere thanks to all who have contributed advice on this problem.

A fine example of why I love the Siduction community, patient, helpful and more than happy to share knowledge.

Cheers all.

[ro_sid]

Alle letztgenannten Maßnahmen gehen soweit in Ordnung, doch eine Anmerkung:
Wenn der "tmpfs"-Eintrag zu /tmp aus der fstab entfernt oder auskommentiert wird, bedeutet das falls "tmp.mount" ausfallen sollte (sic!) und man in grub mit "rw" statt "ro" bootet, daß direkt auf den Datenträger der zugeordneten Partition (meist "/") geschrieben wird. Ist natürlich nicht schlimm, aber "unschön". Mit dem Eintrag sollte (weiterhin) ins RAM ("RAMdisk") geschrieben werden.

[ro_sid]

@scholle1:
Danke für die Erklärung der Hierarchie-Auflösung von systemd.
Frage: Wie paßt /var/lib/systemd da hinein? Es sind dort (bei mir) nicht nur "frische" Einträge des laufenden Systems vorhanden, sondern auch ältere, etwa vom Typ "wants", vermutlich "permanente".

[michaa7]

Ok, seems problem solved for everybody. So only for clarification: Does anybody know what causes the tmpfs entry in fstab, who gets it and who not? On what does it depend?

Is it "god does not throw dice, but systemd does"?

[harley-peter]

Habe hier gerade zwei Systeme aktualisiert, ohne Probleme und ohne zusätzliche Handarbeit. Der fehlerhafte Link wurde automatisch entfernt.
Übrigens hat ein System den ominösen Eintrag in der fstab und das andere nicht, warum auch immer.

Vielen Dank an alle, das war hervorragende Community-Arbeit.

[ro_sid]

Ok, seems problem solved for everybody. So only for clarification: Does anybody know what causes the tmpfs entry in fstab, who gets it and who not? On what does it depend?

Is it "god does not throw dice, but systemd does"?

For me, the entry has come with the Siduction installation. And since this file does not get "updated" with each boot - which is good -, it is either a fixed template or dynamically added (only once), may be from "systemd". That "tmp.mount" file is not so new, existed even at least in Ubuntu 18.04 LTS, though not /lib/systemd, but then in /usr/share/systemd (sic!).
May be, our Siduction "installation wizards" can tell us more about this.

[micspabo]

Vielen Dank an alle, das war hervorragende Community-Arbeit.

Schön gebrüllt Löwe, da schließe ich mich gerne an! 

[dibl]

Vielen Dank an alle, das war hervorragende Community-Arbeit.

+1

Thanks to all the community for the help to work out this little challenge.