system failed to start due to systemd upgrade!

[scholle1]

@ro_sid

systemd is a complexity monster and the opposite of the KISS principle!

Da bin ich voll deiner Meinung und es ist vermutlich auch die eigentliche Ursache für den mnt.mount Fehler.
So unübersichtlich, dass eine verdrehte Unit Ablage nicht auffällt. Was bleibt, das sind die zusätzlichen
Zeilen Code um den kaputten Link zu entfernen. In drei Jahren weiß niemand mehr warum die Laiche
da drin steht.

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".

Das weiß ich auch nicht genau. Die man-page hat dort drei Punkte für weitere, nicht aufgeführte Verzeichnisse und somit sind die Dateien vor /usr/lib/systemd/system einsortiert.
Bei mir enthalten die Einträge mit älterem Datum hauptsächlich leere Verzeichnisse oder solche mit Zeitstempeldateien. Eine Ausnahme bilden die Verzeichnissen deb-systemd-helper-enabled und deb-systemd-user-helper-enabled. In ihnen liegen Dateien mit den Namen von systemd Units und den Endungen .dhs.also. Deren Inhalte sind Zeilen mit Units in /etc/systemd/system/.....target.wants/. Das deutet darauf hin, dass es sich um zeitliche Aktivitäten und Abhängigkeiten aktivierter systemd Units handelt, die hier dokumentiert wurden.

[duroni]

Habe soeben mein System aktualisiert (31.05.2024 / 14:30Uhr). Direkt von 256~rc3-2 auf 256~rc3-6, ohne Probleme und ohne vorherige kopiererei der Datei tmp.mount oder Aenderungen in der fstab. Dort war und ist kein Eintrag mit tmpfs. Der Link von tmp.mount wurde automatisch entfernt.
Tolle Arbeit von Allen und vielen Dank für die hervorragende Community-Arbeit von der ich einmal mehr profitieren durfte. 

Dieter

[ro_sid]

@ro_sid

systemd is a complexity monster and the opposite of the KISS principle!

Da bin ich voll deiner Meinung und es ist vermutlich auch die eigentliche Ursache für den mnt.mount Fehler.
So unübersichtlich, dass eine verdrehte Unit Ablage nicht auffällt. Was bleibt, das sind die zusätzlichen
Zeilen Code um den kaputten Link zu entfernen. In drei Jahren weiß niemand mehr warum die Laiche
da drin steht.

Danke sehr .

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".

Das weiß ich auch nicht genau. Die man-page hat dort drei Punkte für weitere, nicht aufgeführte Verzeichnisse und somit sind die Dateien vor /usr/lib/systemd/system einsortiert.
Bei mir enthalten die Einträge mit älterem Datum hauptsächlich leere Verzeichnisse oder solche mit Zeitstempeldateien. Eine Ausnahme bilden die Verzeichnissen deb-systemd-helper-enabled und deb-systemd-user-helper-enabled. In ihnen liegen Dateien mit den Namen von systemd Units und den Endungen .dhs.also. Deren Inhalte sind Zeilen mit Units in /etc/systemd/system/.....target.wants/. Das deutet darauf hin, dass es sich um zeitliche Aktivitäten und Abhängigkeiten aktivierter systemd Units handelt, die hier dokumentiert wurden.

Danke (ohne !) für diese Erklärung. Bei mir sieht es ähnlich aus Aber wie beim "fstab-/tmp"-Problem wäre es natürlich schön zu wissen, wie sich /var/lib/systemd da einordnet. Nun ja, da muß man dann wohl Herrn Poettering fragen .

[dibl]

... 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?
...

Semi-answer:  This tmpfs for /tmp mount line goes back to the days when SSDs were new technology, and users were seeking techniques to minimize "write" commands on the SSD media. In this old 2012 article, under the "Optimizing SSD-based System Performance" paragraph, you can find it under Item 1.

https://siduction.org/2012/01/ssd-partitioning-partition-alignment-optimal-configuration-settings-and-performance-testing/

Apparently, at some later time, it was adopted as a default for /etc/fstab in siduction.

[Isegrimm666]

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

So kann ich das auch nur ausdrücken und deshalb auch nochmal von mir, besten Dank an alle.

[michaa7]

Thanks dibl.

...
Semi-answer:  This tmpfs for /tmp mount line goes back to the days when SSDs were new technology,...

I assume today it is deprecated ?

Apparently, at some later time, it was adopted as a default for /etc/fstab in siduction.

So, as far as fstab is concerned the hassle was not on systemd.

[ro_sid]

Thanks dibl.

...
Semi-answer:  This tmpfs for /tmp mount line goes back to the days when SSDs were new technology,...

I assume today it is deprecated ?
[...]

Why should it be, deprecated? Some programs create a lot of temporary files rather fast and throw them away immediately afterwards, compilers e.g. Doing this in RAM is as well faster as it also means less strain on any physical device.
I do not remember exactly, but I think, around 2012 tmpfs was not that old and may be came out of its testing phase, as it is useful anyhow, especially for /tmp. And as I wrote above, if tmp.mount fails, this entry will still provide /tmp as a tmpfs.

[michaa7]

I meant deprecated as a ***neccessary*** means  against wearing out SSD quickly.

And if it serves as a fallback as you state, then I have to ask: Is it clear now what *exacly* causes the hang during boot? The broken systemd link or the tmpfs entry in fstab (as charlyheinz still suggests)?

[hendrikL]

The broken symlink was the reason! Because , if you leave it as is without manual intervention, expect removing that symlink before sd 256rc3-6, we wouldn't  recognise it.
Now the challenge is to tell calamares not to generate that fstab entry. on the other hand it doesn't hurt.

[unklarer]

Now the challenge is to tell calamares not to generate that fstab entry. on the other hand it doesn't hurt.

Then use the cli-installer, because it did not do this for me in the fstab.   

[scholle1]

The broken symlink was the reason![...]

It was the secondary error. The primary error was the storage of tmp.mount in /usr/share/systemd. This already happened a few versions before. Someone noticed the first error and moved the unit to /usr/lib/systemd/system (where it belongs) without looking at the link in /etc. This happened in systemd 256~rc3-5, maybe already in systemd 256~rc3-3.

[Isegrimm666]

So ...

... ich habe jetzt ein doas apt full-upgrade auf zwei unterschiedlichen Systemen problemlos durchgeführt.

Wie seht ihr die Durchführung eines dist-upgrades?

Machen oder lassen?

[edlin]

Ein apt dist-upgrade ist nicht erforderlich, da du den gleichen Job bereits mit apt full-upgrade erledigt hast. Zu apt gehört full-upgrade (siehe man apt),, während dist-upgrade aus apt-get stammt. Bleibe einfach bei full-upgrade.

edlin

[Isegrimm666]

Danke ... dann bin ich ja soweit safe.

*verinnerlicht man apt

[dibl]

Thanks dibl.

...
Semi-answer:  This tmpfs for /tmp mount line goes back to the days when SSDs were new technology,...

I assume today it is deprecated ?

It looks to me like the answer is "YES", for Debian Linux.

When I read the paragraph entitled "Reduction of SSD write frequency via RAMDISK" here:

https://wiki.debian.org/SSDOptimization

it looks like the Debian devs intend to replace the /etc/fstab mount line with the systemd unit. (Maybe they didn't get the execution correct, first time out.)

This is also very interesting (to me) and relevant to our subject:

https://lists.debian.org/debian-devel/2012/06/msg00311.html