Guten Morgen allerseits.
Hier zur Warnung:
Nach einem heutigem DU bei dem keine Pakete entfernt und in erster Linie Pipewire und Libre-office aktualisiert wurden bootet mein System nicht mehr durch. Beim Bootvorgang werden diese Meldungen moniert:
Quotefailed to start grub-common.service
Quotefailed to start preload.service
Quotefailed to start exim4.service
Welches aktualisierte Paket das verursacht kann ich leider nicht ausmachen.
Auf einem ähnlichen Rechner habe ich kontrolliert das wirklich keine Pakete bei einem DU entfernt werden.
Hat jemand eine Idee?
Habe auf dem Zweitrechner nochmal recherchiert. Es sieht schwer nach dem Upgrade von systemd aus. Kann das jemand bestätigen, bzw. hat jemand eine Idee wie ich das beheben kann?
Es geht mir (leider) genauso.
Ich hasse diesen "systemd". Bei SysV und "Verwandten" wüßte ich jetzt genau, wie ich aus dieser "Nummer" wieder herauskomme. Im jetzigen Zustand habe ich noch keine Idee, wie ich ein Update hinbekommen soll. Vielleicht geht es über das Live-Medium. Debian hat da immer einen "Rescue"-Boot, "Siduction" hoffentlich auch, das habe ich mir noch nicht angesehen.
Hallo,
hier das gleiche Problem.
"failed to start exim4.service"
Nur Pakete aktualisiert, keine entfernt.
bevo
Es sind ja einige Pakete die in diesem Zusammenhang aktualisiert werden:
Alle in der Versionsnummer 256~rc3-3:
-diverse systemd- Komponenten,
-libnss-myhostname
-libnss-mymachines,
-libudev1,
-udev.
Wie würde in diesem Fall ein downgrade aussehen müssen? So etwas habe ich leider noch nie durchgezogen, zumal ich das ja wahrscheinlich in einer checkroot Umgebung machen müsste.
Oh Gott, oh Gott. Und das ausgerechnet heute, wo ich das System dringend benötige, man...
Argh, dann starte ich meine Kiste vorläufig mal besser nichtb neu.... :(
Ich bin mir nicht sicher, ob ich nach dem systemd Update (war wohl gestern) mein System neu gebootet hatte. Meist suspendiere ich nur. Werde daher vorerst nur in den Standby-Mode runter fahren, bis wir mehr wissen.
So, hab inzwischen meine Testinstallation in VirtualBox nach längerer Zeit aktualisiert. Herunter gefahren und neu gebootet ...
... Das System bootet ganz normal. Jetzt wirds mystisch.
edlin
In EN, in short: systemd seems broken in version 256~rc3-2 and may leed to an unbootable system!!!Quote from: charlyheinz on 2024/05/28, 10:20:10
Habe auf dem Zweitrechner nochmal recherchiert. Es sieht schwer nach dem Upgrade von systemd aus. Kann das jemand bestätigen, bzw. hat jemand eine Idee wie ich das beheben kann?
Als erstes danke für deine Warnung, ich war gestzern schon drauf und dran ein d-u zu fahren ... habe es auf heute verschoben und Gott sei dank hier vorbeigeschaut.
Zur Lösung kann ich wenig beitragen, zumal bislang weder über google noch über den Debian bugtracker entsprechende Fehlerberichte für die neueste Version auffindbar sind.
Hast du versucht im Grub Auswahlmenü den
recovery-mode auszuwählen (den es ja zu jedem Kerneleintrag gibt)? Das führt zwar bei verbogenem systemd auch nicht unbedingt weiter, ist aber nen Versuch wert.
Das downgrade auf die Vorgängerversion ist nicht das eigentliche Problem, das wäre ja mit dpkg und den Versionen in /var/cache/apt/archives einfach durchzuführen.
dpkg -i systemd=256~rc3-2 libnss-myhostname=256~rc3-2 usw ... Dein problem ist ja dass du nichtmal in eine Konsole booten kannst. Wenn das also über das bootmenü nicht zu erzielen ist bleibt nur eine changeroot Umgebung, die aber wohl irgendwo im Handbuch erklärt ist.
Dank chroot helper auf dem Live Medium sollte das aber recht einfach sein. Chroot helper starten, entsprechende partition auswählen und ab die Post.
I am not sure if this helps, but I did a "dist-upgrade" yesterday and can boot into my system.
The packages that can be upgraded now are:
# apt list --upgradable
exfatprogs/unstable 1.2.3-1 amd64 [upgradable from: 1.2.2-1]
ghostscript/unstable 10.03.1~dfsg-1 amd64 [upgradable from: 10.03.1~dfsg~git20240518-1]
libboost-chrono1.83.0t64/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost-filesystem1.83.0/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost-iostreams1.83.0/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost-locale1.83.0/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost-program-options1.83.0/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost-thread1.83.0/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libboost1.83-dev/unstable 1.83.0-3 amd64 [upgradable from: 1.83.0-2.1+b1]
libgs-common/unstable,unstable 10.03.1~dfsg-1 all [upgradable from: 10.03.1~dfsg~git20240518-1]
libgs10-common/unstable,unstable 10.03.1~dfsg-1 all [upgradable from: 10.03.1~dfsg~git20240518-1]
libgs10/unstable 10.03.1~dfsg-1 amd64 [upgradable from: 10.03.1~dfsg~git20240518-1]
libnss-myhostname/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libnss-mymachines/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libnss-resolve/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libnss-systemd/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libpam-systemd/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libsystemd-shared/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libsystemd0/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libudev1/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
libzvbi-common/unstable,unstable 0.2.42-2 all [upgradable from: 0.2.42-1.1]
python3-pytest/unstable,unstable 8.2.1-2 all [upgradable from: 8.2.1-1]
systemd-container/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
systemd-coredump/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
systemd-dev/unstable,unstable 256~rc3-3 all [upgradable from: 256~rc3-2]
systemd-resolved/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
systemd-sysv/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
systemd-timesyncd/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
systemd/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
udev/unstable 256~rc3-3 amd64 [upgradable from: 256~rc3-2]
wsdd/unstable,unstable 2:0.8-1 all [upgradable from: 2:0.7.1-5]
Hopefully this can help identify the packages that need to be downgraded (likely all the '256~rc3-3" ones, down to "256-rc3-2").
Same problem here, you have to downgrade systemd to 256-rc3-2!
How i did it,
First change in the boot command line that ro to rw (read only to read write), boot!
Then add in /etc/apt/source.list.d/debian.list testing
Now apt update && apt install -t testing systemd --no-strict-pinning, but please read what apt wants to do, *READ CAREFULL*
That worked for my system!
#############################################################
Das gleiche Problem hier, systemd muss man downgraden!
Wie ich es gemacht habe,
Zuerst in der Boot-Befehlszeile (command line) ro auf rw (read only to read write) ändern, booten!
Dann in /etc/apt/source.list.d/debian.list testing hinzufügen
Jetzt apt update && apt install -t testing systemd --no-strict-pinning, aber bitte lesen, was apt machen will, * LESEN UND VERSTEHEN*
Hat bei meinem System funktioniert!
@hendrikL
First changing the bootentry to rw let me start my system again. puh
What I didn't know is the exact sourcelist entry to aktivate the debian testing source and I couldn't find any info anywhere in the net.
Can you give me a hint for that entry please.
I'd tried:
Quotedeb http://deb.debian.org/debian testing main contrib non-free
# debian testing
deb https://deb.debian.org/debian/ testing main contrib non-free-firmware
# deb-src https://deb.debian.org/debian/ testing main contrib non-free-firmware
Quote from: edlin on 2024/05/28, 11:55:59
Ich bin mir nicht sicher, ob ich nach dem systemd Update (war wohl gestern) mein System neu gebootet hatte. Meist suspendiere ich nur. Werde daher vorerst nur in den Standby-Mode runter fahren, bis wir mehr wissen.
So, hab inzwischen meine Testinstallation in VirtualBox nach längerer Zeit aktualisiert. Herunter gefahren und neu gebootet ...
... Das System bootet ganz normal. Jetzt wirds mystisch.
edlin
Gerade ausprobiert, strange really strange, meine VM bootet nach "full-upgrade" ganz normal und es ist ein voll funktionsfähiges System!
Ich schließe mich an, jetzt wird es mystisch!
@hendrikL
At first thanks for the hint.
After adding testing in source.list and starting apt as you adviced apt wants to install the new 256~rc3-3 Version of systemd again, no change.
For today I can work with it.
Is it a security problem using rw for the grub starting command.
Quote from: charlyheinz on 2024/05/28, 15:30:34
@hendrikL
At first thanks for the hint.
After adding testing in source.list and starting apt as you adviced apt wants to install the new 256~rc3-3 Version of systemd again, no change.
For today I can work with it.
Is it a security problem using rw for the grub starting command.
Did you run
apt update && apt install systemd/testing --no-strict-pinning
?
~$ LANG=C apt install systemd/testing --no-strict-pinning -s
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
systemd is already the newest version (256~rc3-2).
Selected version '256~rc3-2' (Debian:testing [amd64]) for 'systemd'
Selected version '1.5.3-7' (Debian:unstable, Debian:testing [amd64]) for 'libpam0g' because of 'systemd'
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 13
Notice: Automatically enabled --solver 3.0 for --no-strict-pinning
LANG=C apt policy systemd
systemd:
Installed: 256~rc3-2
Candidate: 256~rc3-4
Version table:
256~rc3-4 500
500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
256~rc3-3 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
*** 256~rc3-2 500
500 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
Btw. 256rc3-4 has the same problem, I don't know what is causing that issue!
@charlyheinz
If everything runs again like expected, I would suggest thinking about using timeshift in future. This lets you look in a more relaxed way on such problems. You can restore your system with just a few clicks, even if it refuses to boot.
Ich habe seit heute morgen insgesamt 5 Systeme mit D-U aktualisiert.
Jetzt komme ich in's Forum und sehe die Warnung. Alle haben
apt policy systemd
systemd:
Installiert: 256~rc3-3
Installationskandidat: 256~rc3-3
Versionstabelle:
*** 256~rc3-3 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
und alle starten, wie immer . 8) Extra jetzt überprüft.
Allerdings war mir mit apt-listchanges das hier aufgefallen (übersetzt):
apt-listchanges: Neuigkeiten
----------------------------
systemd (256~rc2-3) unstable; dringlichkeit=medium
- /tmp/ ist nun standardmäßig ein tmpfs, und zwar über die vorgelagerte Unit tmp.mount.
Die vorherige Einstellung kann beibehalten werden, indem man die Unit lokal mit maskiert:
systemctl mask tmp.mount
oder:
touch /etc/systemd/system/tmp.mount
- /run/lock/ wird nicht mehr mit einem Patch vor dem Start der Units erstellt, sondern durch
eine standardmäßige early-boot run-lock.mount Einheit, die vor
local-fs.target. Jeder Dienst, der /run/lock/ verwenden muss und vor
sysinit.target läuft (d.h. sie definieren wahrscheinlich DefaultDependencies=no), muss
explizit mit After=run-lock.mount bestellt werden. Die beiden bekannten Fälle
wo dies im Archiv passiert, wurde bereits ein Bug+MR eingereicht.
- Bei neuen Installationen bereinigt tmpfiles.d nun standardmäßig /tmp/ alle
10 Tage, und /var/tmp/ alle 30 Tage. Das alte Verhalten kann konfiguriert werden
mit einer lokalen Überschreibung konfiguriert werden, falls erforderlich:
echo 'D /tmp 1777' > /etc/tmpfiles.d/tmp.conf
Diese Überschreibung wird automatisch für Upgrades von bestehenden
Systemen von früheren Versionen auf Trixie. Zur Erinnerung, einzelne
Dateien und Verzeichnisse für den Ausschluss von Bereinigungen markiert werden
der Konfigurationszeile vom Typ 'x', wie in der tmpfiles.d-Manpage beschrieben,
zum Beispiel:
echo 'x /tmp/my-precious' > /etc/tmpfiles.d/precious.conf
- Coredumps werden nun standardmäßig über Konfigurationsdateien deaktiviert, anstatt
ein Out-of-Tree-Patch (die Installation des optionalen Pakets systemd-coredump
wird sie wie bisher aktivieren). Wie immer ist ein Überschreiben über lokale Drop-ins
möglich, falls gewünscht. Die Konfigurationsdateien, die sich jeweils auf
die systemd-Instanz, die systemd-Instanzen der Benutzer und die PAM-Sitzungen
sind:
/usr/lib/systemd/system.conf.d/10-coredump-debian.conf
/usr/lib/systemd/user.conf.d/10-coredump-debian.conf
/usr/lib/sysctl.d/10-coredump-debian.conf
/etc/security/limits.d/10-coredump-debian.conf
-- Luca Boccassi <bluca@debian.org> Tue, 28 May 2024 00:07:57 +0100
...
systemd (256~rc3-3) wird eingerichtet ...
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
...
My system boots now without problems.
I was checking my fstab, and I knew that I mount my tmp as tmpfs!
~$ cat /etc/fstab
# Neue Partition none defaults 0 0 # /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=385C-E2B7 /boot/efi vfat umask=0077 0 2
UUID=009a5764-2ac7-41d0-9a9f-f80285bfb34e / ext4 noatime 0 1
tmpfs /tmp tmpfs noatime,mode=1777 0 0
UUID=6134a4d8-1a1b-46e2-99da-4263c146ef57 /ablage ext4 noatime 0 1
UUID=41a8bbb8-076c-49bf-9e0e-e05102319636 /speicher ext4 defaults,noatime 0 1
But, look at the topline, "neue Partition" / "New partition" ! Wtf!
I commented it out and run an apt full-upgrade, rebooted and everything is ok!
Where does that first line came from?
systemd wurde soeben auf 256~rc3-4 aktualisiert
systemd (256~rc3-4) wird eingerichtet ...
Unit tmp.mount does not exist, proceeding anyway.
Created symlink '/run/systemd/system/tmp.mount' → '/dev/null'.
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
systemd-timesyncd (256~rc3-4) wird eingerichtet ...
Hier ist immer noch kein Fehler mit systemd beim Neustart vorhanden. Also, neues D_U ;)
Ich hab mir nun mal mein Surface Go als unrelevantesten Rechner hergenommen. Per nala upgrade upgedated inklusive systemd 256~rc3-4. Neustart und das Teil hängt. Nu kann ich entweder per Timeshift zurück oder die Pakete downgraden, oder einfach mal abwarten. Die neuere Systemd Version scheint aber nicht der Heilsbringer zu sein.
Meine fstab sieht aber unverändert und für mich völlig OK aus - allzu viel steht da eh nicht drin:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=D1BA-0A70 /boot/efi vfat umask=0077 0 2
UUID=6b732649-6f66-4cf6-93f5-e165b7dbd4a2 / ext4 defaults,noatime 0 1
UUID=eef0a3b3-2c30-488c-ae5e-151bfd9dc437 swap swap defaults,noatime 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Here still the same. I just did a DU while the new systemd rc was installed with the effect like befor, that my system stops booting. With changing the rw option for grub the system is starting!
I also checked my fstab. Nothing changed in it. tmpfs = /tmp and no new entry on top of it!
Quoteapt policy systemd
systemd:
Installiert: 256~rc3-4
Installationskandidat: 256~rc3-4
Strange! Ich hab jetzt auch mal meine Hauptmaschine neu gestartet. Wie zu Erwarten hing auch die. Hab dann mit Option rw gestartet und war dann etwas sprachlos. Meine fstab war zwar unverändert, aber sie wurde in weiten Teilen einfach ignoriert. Sämtliche Partitionen, die mit der Option nofail vermerkt sind, wurden nicht eingehängt.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=E77B-D732 /boot/efi vfat umask=0077 0 2
UUID=a5c66fc1-d6ae-429e-895d-f8caaf57962f / ext4 defaults,noatime 0 1
UUID=5a7f9898-e98e-4c83-8d34-c61f5d30ea82 /home ext4 defaults,noatime 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
UUID=159ac537-428c-482d-b510-9e6cd0819302 none swap sw 0 0
UUID=bc860344-b048-4d13-bf1c-d5ea78a4c064 /media/Bilder ext4 defaults,noatime,discard,nofail 0 2
UUID=fcd041ed-d818-495c-aa13-cfbe895da4a7 /media/Musik ext4 defaults,noatime,discard,nofail 0 2
UUID=44f3673f-b742-4385-8743-55251f4eba16 /media/Video ext4 defaults,noatime,discard,nofail 0 2
UUID=b082c72a-9326-4990-a959-b71593d85f8b /media/Sicherung ext4 defaults,noatime,discard,nofail 0 2
Bin jetzt erstmal via timeshift auf den Stand von gestern zurückgekehrt und bleib da erstmal, bis Entwarnung gegeben wird.
Nach D-U bootete Siduction bei mir auch nicht mehr. :(
Im Boot-Menü auf dem aktuellen Boot-Eintrag 'e' drücken und unten ro gegen rw ändern,- mit F10 dann booten. Ist bei mir erfolgreich und ich komme wieder in mein System.
@hendrikL: Danke! :D
Das Paket systemd läuft mit Version 256~rc3-4
Die apt-listchanges zu systemd (256~rc3-3) hatte ich zwar gelesen, aber nicht erwartet, das mir das beim Reboot um die Ohren fliegt.
Meine /etc/fstab hat sich seit Februar nicht geändert.
Da hab ich die Transition von t64 überlebt, und heute dumm aus der Wäsche geschaut als mein reboot klemmte.
First. I don't think that it is a good idea to always boot by changing the command line. Please downgrade!
charlyheinz please do it, all other too!
Then try to find the reason why this happens, there must be something wrong/ not right on your system.
When you boot without changing the command line, you can always login by changing to getty 2 or 3 or ... then start searching for the error by reading for example dmesg or journalctl, try startx and so on, you can akso try the mount command, ..., there are many ways to check and search...!
But please downgrade, or start a rollback, always boot with changing ro to rw is the last thing you should do!
After DU this morning evrything still the same, my system is not booting. With changing the grub-bootentry to rw it works, but as hendrikLmeant it is for shure not a solution. Still try to find the reason for this behavior with my small experience.
Quoteapt policy systemd
systemd:
Installiert: 256~rc3-5
Installationskandidat: 256~rc3-5
charlyheinz, what are you doing is the best way to shoot in your feed!
mount ro but to init 3 if you try to find the reason why, than try 'mount a -- rw,' than startx as user, getty is still working!
on the command line, type a 3 at the end. then you are booting to init 3 directly and start searching.
Danke hendrikL
Ich denke es ist mal wieder an der Zeit mein System frisch aufzusetzen. Timeshift kannte ich bis jetzt noch nicht. (klasse!)
Gibt es Bedenken hinsichtlich der System-Sicherheit beim Umstellen des Booteintrags auf rw?
Selbstverständlich ist das keine Lösung. Ausgerechnet diese Woche habe ich keine Zeit für Experimente.
Wird es eigentlich demnächst ein neues Release geben?
Danke an alle Beteiligten!!
wenn plasma 6, bzw. kf6 in debian unstable aufschläg und funktionsfähig ist, dann neues offizielles ISO, bis dahin gibt es aktuelle Test-ISOs. Ab und an halt.
Gerade gibt es ein neues kde, zum Testen, ohne Garantie!
Quote from: charlyheinz on 2024/05/29, 08:38:09
Ich denke es ist mal wieder an der Zeit mein System frisch aufzusetzen. Timeshift kannte ich bis jetzt noch nicht. (klasse!)
Nur zur Sicherheit:
Wenn Du Timeshift auf Deinem neu aufgesetzten System installierst, nicht vergessen, dass bei siduction der cron.service standardmäßig nicht aktiviert ist. Den musst einmalig aktivieren. Als root:
systemctl enable cron.service Sonst laufen die automatischen Sicherungen nicht.
Quote from: hendrikL on 2024/05/29, 10:09:45
Gerade gibt es ein neues kde, zum Testen, ohne Garantie!
Vor einer halben Stunde installiert
https://testbuilds.siduction.org/kde/siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202405290730.iso (https://testbuilds.siduction.org/kde/siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202405290730.iso)
problemlos auf Btrfs, reboot, DU 6 Pakete, reboot.
Funktioniert jetzt alles einwandfrei.
Edit:
# apt policy systemd
systemd:
Installiert: 256~rc3-5
Installationskandidat: 256~3-5
Versionstabelle:
*** 256~rc3-5 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
I reverted to rc 3-2 as above and it all works OK however I just tried installing rc 3-5 as it seems to work for some and it fails so I am now back to rc 3-2
Tried to downgrade as per HendrikL's instructions but it won't downgrade.
apt install -t testing systemd --no-strict-pinning
systemd is already the newest version (256~rc3-5).
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
Notice: Automatically enabled --solver 3.0 for --no-strict-pinning
I check and it is available.
apt policy systemd
systemd:
Installed: 256~rc3-5
Candidate: 256~rc3-5
Version table:
*** 256~rc3-5 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
500 http://ftp.ca.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
256~rc3-2 500
500 https://deb.debian.org/debian testing/main amd64 Packages
Is there something else that needs to be done in order to downgrade like this?
Try
apt install systemd=256~rc3-2 libnss-myhostname=256~rc3-2 <all-other-related-systemd+udev-files=256~rc3-2>
apt install -t testing systemd/testing ........
Auf einem Testsystem habe ich versucht wie im 1. posting von hendrikl auf rc 3-2 zurück zu gehen.
Habe mir aber rc 3-5 eingefangen und gleicher Fehler. Auf diesem System ließ sich X nicht starten.
Auf meinem Hauptrechner funktioniert der Eintrag 3 am Ende der command line nicht.
Es ist zum Mäuse melken >:(
That worked! Downgraded 10 packages and rebooted normally.
I'm away for two weeks and this machine won't be used so hopefully by then this will be sorted.
Thanks @michaa7
löschen
mh, hinter das systemd noch mal testing systemd/testing, sollte eigentlich funktionieren, ansonsten ja mit =256....
so gings bei mir .. testing aktivieren und dann:
apt install systemd=256~rc3-2 libsystemd-shared=256~rc3-2 libsystemd0=256~rc3-2 --no-strict-pinning
Kann jemand von den betroffenen Systemen hier seine fstab auf diesen Eintrag überprüfen?
tmpfs /tmp tmpfs noatime,mode=1777 0 0
Und, wenn sie ihn haben, ihn auskommentieren, neu starten, um zu sehen, ob der Fehler verschwunden ist?
Ich habe keinen solchen Eintrag in meinen fstabs.
====================
Can anyone here, from the affected systems, check their fstab for this entry?
--
And, if they have it, comment it out, reboot to see if the error is gone?
I don't have such an entry in my fstab's.
Und noch einmal. wenn ihr wieder ein funktionierendes system habt, schaut, wo der Fehler liegen kann.
Z. B. falscher fstab Eintrag, oder hat sich etwas an der cmd-line, boot Zeile geändert, schaut nach, denn ansonsten werdet ihr ewig diesen Fehler mit Euch schleppen, dmesg, journalctl, irgendwelche Fehlermeldung, andere Auffälligkeiten.
systemd reagiert da nur auf etwas!
----------------------------------------------
And once again, if you have a functioning system again, see where the error may lie.
For example, wrong fstab entry, or has something changed in the cmd-line, boot line, check, because otherwise you will carry this error with you forever, dmesg, journalctl, any error message, other anomalies.
systemd only reacts to something!
~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=385C-E2B7 /boot/efi vfat umask=0077 0 2
UUID=009a5764-2ac7-41d0-9a9f-f80285bfb34e / ext4 noatime 0 1
tmpfs /tmp tmpfs noatime,mode=1777 0 0
UUID=6134a4d8-1a1b-46e2-99da-4263c146ef57 /ablage ext4 noatime 0 1
UUID=41a8bbb8-076c-49bf-9e0e-e05102319636 /speicher ext4 defaults,noatime 0 1
hhl@hhl-2:~$ LANG=C apt policy systemd
systemd:
Installed: 256~rc3-5
Candidate: 256~rc3-5
Version table:
*** 256~rc3-5 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
100 /var/lib/dpkg/status
256~rc3-2 500
500 https://deb.debian.org/debian testing/main amd64 Packages
No problem so far!
Und auch eine Neuinstallation mit dem Testiso von heute hat diesen fstab-Eintrag und bootet problemlos.
And also a new installation with the testiso from today has this fstab entry and boots without problems.
@hendrikL
Verstehn ich Dich richtig, dass bei Dir nach der Korrektur Deiner mysteriösen fstab Zeile Du nun mit den neusten systemd Versionen problemlos booten kannst?
hmm, als ich vorhin mit 256~rc3-5 den mc starten wollte, wurde mir gemeldet, das mc keine tmp anlegen kann ... fiel mir nur so auf .. keine ahnung obs hilft :-[
Quote from: Fellfrosch on 2024/05/29, 16:27:35
@hendrikL
Verstehe ich Dich richtig, dass bei Dir nach der Korrektur Deiner mysteriösen fstab Zeile Du nun mit den neusten systemd Versionen problemlos booten kannst?
So ist es, ja!
:~$ inxi -Sa
System:
Host: hhl-2 Kernel: 6.9.2-1-siduction-amd64 arch: x86_64 bits: 64
compiler: gcc v: 13.2.0 clocksource: tsc avail: hpet,acpi_pm
parameters: initrd=\3c3ddd603b3346d4ac5cc56721efbd2d\6.9.2-1-siduction-amd64\initrd.img-6.9.2-1-siduction-amd64
root=UUID=009a5764-2ac7-41d0-9a9f-f80285bfb34e ro quiet splash
systemd.machine_id=3c3ddd603b3346d4ac5cc56721efbd2d
Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.13 info: frameworks
v: 5.115.0 wm: kwin_wayland vt: 2 dm: SDDM Distro: siduction 22.1.2
Masters_of_War - kde - (202303151559) base: Debian GNU/Linux trixie/sid
Ich hab jetzt mal trotzdem den Hinweis von @unklarer ausprobiert
Siehe da die Kiste bootet. Ich probier nu mal mit der Zeile ein bisserl rum. Werde berichten.
Quote from: unklarer on 2024/05/29, 16:13:05
...
Can anyone here, from the affected systems, check their fstab for this entry?
--
And, if they have it, comment it out, reboot to see if the error is gone?
YES!
I have this ancient museum item:
System:
Host: don-presario Kernel: 6.8.10-1-siduction-amd64 arch: x86_64 bits: 64
Desktop: LXQt v: 1.4.0 Distro: siduction 2023.1.1 giants - lxqt -
(202309091910)
Machine:
Type: Laptop System: Hewlett-Packard product: Presario CQ56 Notebook PC
v: 058D100002242810010620100 serial: <superuser required>
Mobo: Hewlett-Packard model: 1604 v: 88.17 serial: <superuser required>
BIOS: Hewlett-Packard v: F.18 date: 04/18/2011
Battery:
ID-1: BAT0 charge: 37.3 Wh (89.0%) condition: 41.9/41.9 Wh (100.0%)
CPU:
Info: single core AMD V140 [UP] speed (MHz): 2300 min/max: 800/2300
Graphics:
Device-1: AMD RS880M [Mobility Radeon HD 4225/4250] driver: radeon v: kernel
Display: x11 server: X.Org v: 21.1.11 driver: X: loaded: radeon
unloaded: fbdev,modesetting,vesa dri: r600 gpu: radeon
resolution: 1366x768~60Hz
API: OpenGL v: 4.5 compat-v: 3.3 vendor: mesa v: 24.0.8-1 renderer: AMD
RS880 (DRM 2.50.0 / 6.8.10-1-siduction-amd64 LLVM 17.0.6)
Network:
Device-1: Qualcomm Atheros AR9285 Wireless Network Adapter driver: ath9k
Device-2: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169
Drives:
Local Storage: total: 111.79 GiB used: 9.6 GiB (8.6%)
Info:
Memory: total: 8 GiB note: est. available: 7.52 GiB used: 2.32 GiB (30.8%)
Processes: 199 Uptime: 5m Shell: Bash inxi: 3.3.34 I broke it Monday before I read this forum. Using the rw on boot line, and booting to run level 3, I have updated it through this morning. (I have 4 KDE/Plasma systems that were saved by the first post here.)
systemd:
Installed: 256~rc3-5
Candidate: 256~rc3-5
Version table:
*** 256~rc3-5 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status # /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=7A0D-BB1C /boot/efi vfat umask=0077 0 2
UUID=4f510b39-82f2-4622-90e0-5863d0403099 /boot ext2 defaults,noatime 0 2
UUID=3cadef2d-6a86-4d4d-b02d-2a32a875d226 / ext4 defaults,noatime,commit=120 0 1
UUID=1fcaa3bd-cbb0-4efa-9b21-9c23e7e05a8d /home ext4 defaults,noatime,commit=120 0 2
# tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
I am posting from this LXQt desktop -- it boots to the GUI with the tmpfs line commented out.
DE:
Ich bin verwirrt. Auch mein system hat nach dem heutigen problemlosen d-u systemd-256~rc3-5 (rc3-3 und rc-4 wurden nie intalliert!) installiert, aber *keinen*
tmpfs /tmp Eintrag in der /etc/fstab.
Weiß hier jemand unter welchen Bedingungen diese Zeile zugefügt wird/werden muß?
EN:
I am confused. After todays d-u I have systemd-256~rc3-5 (rc3-3 und rc-4 were never installed!) , no problem, but also no tmpfs /tmp entry in /etc/fstab.
Anyone has a clue under which circumstances this new entry has to be created and when, as in my case, it's apparently not needed?
@Michaa7
Ich finde es auch sehr seltsam, ich habe ein funktionierendes System mit jenem fstab Eintrag und auch ohne jenem!
------
I also find it very strange, I have a working system with that fstab entry and also without it!
Hmmmm ich hab nu mal den tempfs Eintrag auf nofail gesetzt. damit bootet (wie erwartet) die Kiste.
Dann hab ich mir über mount anzeigen lassen, was eingehängt wurde. Kein tmpfs auf /tmp.
Dennoch hab ich ein /tmp Verzeichnis und da schreibt systemd auch rein:
/tmp$ ls -l |grep systemd
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-bluetooth.service-OPJW41
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-colord.service-BcmfKt
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-exim4.service-0PYjNp
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-haveged.service-9nagIM
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-iwd.service-OdHx7K
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-ModemManager.service-6fcrlH
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-polkit.service-NuiM3Y
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-switcheroo-control.service-Ic7Byc
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-systemd-logind.service-KpsMLg
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-systemd-timesyncd.service-NnMQgo
drwx------ 3 root root 4096 29. Mai 16:54 systemd-private-3402ea97344d41d7bc30c9a45cccf11b-upower.service-fPyl4r
Ich fürchte das übersteigt meine Linux-Fähigkeiten/Kenntnisse
dank @reddark bin ich jetzt wenigstens wieder auf rc3-2.
fstab Eintrag ist " tmpfs /tmp tmpfs noatime,mode=1777 0 0 "
Mal sehen wie es morgen weiter geht :-\
Danke an alle die hier helfen!
bevo
@hendrikL
Kannst Du mal schauen, ob bei Dir
/usr/lib/systemd/system/tmp.mount
vorhanden ist und was da drin steht. Bei mir steht da Folgendes:
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target
[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
Kann es sein, dass der Eintrag in der fstab sich mit der systemd Unit ins Gehege kommt?
:~$ cat /usr/lib/systemd/system/tmp.mount
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target
[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
Zu Deiner Frage, das Ganze übersteigt langsam meine Linux-Kenntnisse.
Starte ich mit jenem Eintrag und grepe bei mount danach, erscheint
$ mount | grep tmpfs | grep /tmp
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
und ohne diesen Eintrag
mount | grep tmpfs | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64
First of all,- I just had to comment out the line from /etc/fstab
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
and I am able to boot normally with ro again. There is no downgrade of systemd neccessary for me.
# cat file /usr/lib/systemd/system/tmp.mount
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target
[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
# ls -ld /tmp
drwxrwxrwt 1 root root 2,3K 29. Mai 17:59 /tmp
:) I am up and running again. :) Hope someone is able to explain what's the culprit in this case.
so, hab tmpfs auskommentiert und ein neues upgrade drüber laufen lassen.
computer läuft 8)
die datei /usr/lib/systemd/system/tmp.mount war vorher nicht vorhanden, nun ist sie es:
$ cat /usr/lib/systemd/system/tmp.mount
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target
[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
Unfortunately I think just commenting out the line in fstab means /tmp is not mounted as a tmpfs anymore, but is a simple directory under root.
@hendrikL showed, that it should be listed with the mount command. On my system it isn't listed. The systemd unit isn't active on my system as well and I'm on top not able to activate it:
systemctl enable tmp.mount
Failed to enable unit: Unit tmp.mount does not exist
But systemd was always and will probably stay for some time longer an enigma to me.
I fear I'm helpless on this.
@Fellfrosch
existiert /usr/lib/systemd/system/tmp.mount?
Klar, wer lesen kann, ist im Vorteil!
Vielleicht systemd neu installieren, mit allem Drum und Dran, apt install --reinstall systemd systemd-<foo> usw.!?
Quote from: Fellfrosch on 2024/05/29, 17:44:51
...
Kann es sein, dass der Eintrag in der fstab sich mit der systemd Unit ins Gehege kommt?
EN: Is it possible that the tmpfs entry in fstab is in conflict with the systemd unit tmp.mount?
Apparently so.
However, here is a good running system that was fully upgraded as of last Sunday (26 MAY) and as you see, it has both the tmpfs entry in fstab, and the tmp.mount unit, with no problem booting to X.
System:
Host: dibl-MOW Kernel: 6.8.10-1-siduction-amd64 arch: x86_64 bits: 64
Desktop: KDE Plasma v: 5.27.11 Distro: siduction 22.1.2 Masters_of_War -
kde - (202303151559)
Machine:
Type: Desktop Mobo: ASUSTeK model: ROG STRIX X299-E GAMING v: Rev 1.xx
serial: <superuser required> UEFI: American Megatrends v: 1401
date: 05/21/2018
CPU:
Info: quad core Intel Core i7-7740X [MT MCP] speed (MHz): avg: 800
min/max: 800/4500
Graphics:
Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nouveau v: kernel
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 24.1.0 driver: X:
loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau
resolution: 1: 1920x1200~60Hz 2: 1920x1080~60Hz
API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 24.0.8-1 renderer: NV136
Network:
Device-1: Intel Ethernet I219-V driver: e1000e
Drives:
Local Storage: total: 4.1 TiB used: 748.76 GiB (17.8%)
Info:
Memory: total: 32 GiB available: 31.27 GiB used: 1.95 GiB (6.2%)
Processes: 276 Uptime: 3h 25m Shell: Bash inxi: 3.3.34
don@dibl-MOW:~$ sudo apt policy systemd
systemd:
Installed: 256~rc3-2
Candidate: 256~rc3-5
Version table:
256~rc3-5 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
*** 256~rc3-2 100
100 /var/lib/dpkg/status
don@dibl-MOW:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=F765-9806 /boot/efi vfat umask=0077 0 2
UUID=f1bd917e-47c9-43dd-bed8-b9ccdc518968 /boot ext2 defaults,noatime 0 2
UUID=9cdc98b4-ebed-478d-9d14-0ebfb4613543 / ext4 defaults,noatime,errors=remount-ro,commit=120 0 1
UUID=b7eb0948-83b6-4a2a-8724-12e258a0c5fb /home ext4 defaults,relatime,errors=remount-ro,commit=120 0 2
UUID=44ee6177-c0e3-47e7-aee7-6c4a74c63c4d /mnt/DATA btrfs noatime,compress=lzo,space_cache=v2 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
don@dibl-MOW:~$ cat /usr/lib/systemd/system/tmp.mount
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target
[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
[Install]
WantedBy=local-fs.targetI have 3 more systems configured like this one, a desktop and 2 laptops, and they all run error-free.
So, this "conflict" is a new feature of the updated systemd, I guess.
The changelog for systemd 256~rc3-3 says: Make /tmp/ a tmpfs by default. Restore the upstream default and make /tmp/ a tmpfs.
Can be overridden with:
touch /etc/systemd/system/tmp.mount
or:
systemctl mask tmp.mount
So it seems, it's not a bug, but a feature, that was badly communicated. Can someone test this on bare metal please, I can't free any hardware right now.
Quote from: devil on 2024/05/29, 18:54:32
...
Can be overridden with:
...
LOL -- yes, AFTER YOU HAVE BOOTED YOUR BORKED SYSTEM!
Ha ha ha --- the joke is on us! ::)
Thanks, @devil -- mystery solved.
There is something fishy.
I rolled back with timeshift. Disabled the fstab entry. Enabled the tmp.mount unit via systemctl enable tmp.mount rebooted. Everything looks good. tmp is mounted as tmpfs.
Now I did the update to 256~rc3-5
Reboot. tmp isn't mounted anymore as tmpfs.
systemctl list-unit-files | grep bad
tmp.mount bad enabled
So what does that mean, that the unit is in a bad state. How do I get more infos on what systemd dislikes?
Quote from: devil on 2024/05/29, 18:54:32
The changelog for systemd 256~rc3-3 says: Make /tmp/ a tmpfs by default. Restore the upstream default and make /tmp/ a tmpfs.
Can be overridden with:
touch /etc/systemd/system/tmp.mount
or:
systemctl mask tmp.mount
So it seems, it's not a bug, but a feature, that was badly communicated. Can someone test this on bare metal please, I can't free any hardware right now.
bedeutet tmpfs in der fstab wieder aktivieren und dann diese befehle ausführen??
Dear diary. This is the last entry for today. ;)
I did
touch /etc/systemd/system/tmp.mount
Now tmp.mount wasn't listed as bad anymore, but as masked. I unmasked it via
systemctl unmask tmp.mount
After that I rebooted, with still deactivated line in fstab.
Result:
tmp is now mounted as tmpfs like it should. So for now I'm at least satisfied.
@devil or anybody else who has more knowledge then me. As I have already written, I'm no expert regarding systemd. Have You some hints for me?
Why is touching an already existing file changing things?
What does masking do? I thought masking means hiding a process. But it seems that I'm wrong with this assumption.
Quote from: devil on 2024/05/29, 18:54:32
Can be overridden with:
Bei mir ist /etc/systemd/system/tmp.mount ein toter Link weil /usr/
share/systemd/tmp.mount nicht mehr existiert.
Der Link zeigt auf /usr/share und nicht auf /usr/lib , wo tmp.mount tatsächlich ist!
Dazu:
Absichtlich frische Installation siduction.....-kde-amd64-
202405152113.iso auf ext4.
In dieser Installation fehlt die "tmp"-Zeile in der fstab.
(Habe die Zeile bei vielen anderen Installationen seit Jahren in der fstab. Benutze meist Btrfs Dateisystem.)
dann DU
systemd von 256~rc2-3 zu 256~rc3-5
Vor DU
# journalctl -b | grep "/tmp"
Mai 29 18:06:05 pc2 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Mai 29 18:06:05 pc2 systemd[1]: Mounting tmp.mount - Temporary Directory /tmp...
Mai 29 18:06:05 pc2 systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
Nach DU
# journalctl -b | grep "/tmp"
Mai 29 19:12:54 pc2 systemd[1]: tmp.mount: Failed to open /etc/systemd/system/tmp.mount: No such file or directoryBoot fehlerfrei vor und nach DU.
Also will systemd "tmp.mount" ausführen, aber es ist keine "tmp" Zeile in fstab und nach DU die systemd-Unit "tmp.mount" nicht erreichbar, da der tote Link (s.o.) wie eine Maskierung wirkt. Sieht so aus als wissen sie bei systemd selbst nicht genau was sie da veranstalten.
Nach "rm /etc/systemd/system/tmp.mount" ist die Funktion wieder wie vor dem DU.
Aber
1. Ich hatte vor und nach dem DU kein Bootproblem.
2. Das DU hat die systemd-version 256~rc3-2 und 256~rc3-3 übersprungen. (Von rc
2-3 zu rc3-5)
Thanks for all the hints. They were very helpful to me.
I did the same two steps as Fellfrosch, but unmasking tmp.mount showed
Unit tmp.mount does not exist, proceeding anyway.
Removed '/etc/systemd/system/tmp.mount'.
Nevertheless,- after a reboot
# systemctl is-enabled tmp.mount
enabled
# systemctl is-active tmp.mount
active
# systemctl status tmp.mount
Active: active (mounted) since Wed 2024-05-29 21:08:08 CEST; 14min ago
Siduction systemd[1]: Mounting tmp.mount - Temporary Directory /tmp...
Siduction systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
# mount | grep tmpfs | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=16085924k,nr_inodes=1048576,inode64)
@Fellfrosch
masking a service will make it impossible for the system to sideload
it, even if an unforseen part of the system still tries to start it.
Quote from: Fellfrosch on 2024/05/29, 20:32:02
touch /etc/systemd/system/tmp.mount
You have overwritten the dead link to /usr/share/.. with this.
Quotesystemctl unmask tmp.mount
and the command removes file /etc/systemd/system/tmp.mount.
Another way - same result.
Wie sagt man auf englisch: Well done. :D
so siehts jetzt bei mir aus ...
$ systemctl is-enabled tmp.mount
generated
$ systemctl is-active tmp.mount
active
$ systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Wed 2024-05-29 21:56:15 CEST; 2min 7s ago
Invocation: 1391d16a0edc412a9ebc1d67510a78a7
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 38092)
Memory: 8.0K (peak: 2.5M)
CPU: 5ms
CGroup: /system.slice/tmp.mount
Mai 29 21:56:15 laptop1 systemd[1]: Mounting tmp.mount - /tmp...
Mai 29 21:56:15 laptop1 systemd[1]: Mounted tmp.mount - /tmp.
$ mount | grep tmpfs | grep /tmp
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
Confirm that the solution from Fellfrosch is working on my system.
had to implement the change ro ==> rw in the boot command to be able to boot.
Many Thanks for this help !
Danke für die Erklärungen. Bin ich ja froh, dass ich als blindes Huhn trotzdem in die richtige Richtung marschiert bin. 8)
I noticed this morning that the tmp.mount link was dead when I was poking around and repaired it as mentioned. At the time though I wasn't aware of the new fstab line. So now with tmp.mount repaired and the fstab line commented I did a D-U to the current systemd and rebooted. Everything seems normal. Wonderful!
A little more poking around.
Dmesg shows nothing I can see but:
journalctl -b | grep "/tmp"
May 29 17:36:15 hp8470p systemd-tmpfiles[740]: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
May 29 17:36:15 hp8470p systemd-tmpfiles[740]: Opening file "/tmp/.ICE-unix/3583" failed, ignoring: No such device or address
I'm not sure if this is related or not.
I have posted a bug report upstream for this issue here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072187
The steps I used to resolve the issue are in the report itself. In a nutshell, /etc/systemd/system/tmp.mount is a broken symlink. I needed to comment out the fstab entry, and "cp /usr/lib/systemd/system/tmp.mount /usr/share/systemd/tmp.mount" to (optionally) restore tmpfs functionality.
systemd is a complexity monster and the opposite of the KISS principle!
Explanation to what happens, and why:
Entries in /etc/systemd/... overwrite/take precedence over (other) existing systemd files in (very) different locations (like /usr or /var). Thus a dangling symbolic link invalidates ("masks"?) its function.
Just "eliminating" it in /etc/systemd makes it work again, if there is a valid entry in one of the other locations. You can do this by e.g. just removing it or giving it another extension (If I do not want to remove it for some reason, I always append a .old extension to its name; let us hope systemd will never use an "old" service/target or whatsoever).
It is not necessary, to have an entry in /usr/share/systemd, as long as no link with higher precedence points to it - an entry in /usr/lib/systemd is sufficient.
You do not have to eliminate the entry in /etc/fstab, as long as it does not contradict the systemd service.
By the way, I had a second (dangling) entry to "tmp.mount" in /etc/systemd/system/local-fs.target.wants/, which I, of course, "invalidated", too.
PS: Thanks for pointing out, that "cron" is disabled by default in Siduction. I would never have assumed this! And, of course, enabled it immediately for things like "logrotate" etc.
While OFFTOPIC for this thread about tmpfs/systemd/tmp.mount, just a quick one for @ro_sid:
Quote from: ro_sid on 2024/05/30, 02:19:00
... PS: Thanks for pointing out, that "cron" is disabled by default in Siduction. I would never have assumed this! And, of course, enabled it immediately for things like "logrotate" etc.
On my system 'systemctl list-timers --all' tells me that logrotate.timer calls logrotate.service on a daily base (and lists several other timers like plocate-updatedb.timer, anacron.timer, man-db.timer...)
Auch bei mir voller Erfolg. Nach kopieren von tmp.mount:
Quotecp /usr/lib/systemd/system/tmp.mount to /usr/share/systemd/tmp.mount"
bootet das System wieder einwandfrei.
Einträge in der fstab bezüglich "tmpfs /tmp" waren nicht ergänzt und sind auch Keine auskommentiert. Den Eintrag habe ich so belassen wie er immer schon war.
Danke an Alle
Quote from: der_bud on 2024/05/30, 08:49:54
While OFFTOPIC for this thread about tmpfs/systemd/tmp.mount, just a quick one for @ro_sid:
Quote from: ro_sid on 2024/05/30, 02:19:00
... PS: Thanks for pointing out, that "cron" is disabled by default in Siduction. I would never have assumed this! And, of course, enabled it immediately for things like "logrotate" etc.
On my system 'systemctl list-timers --all' tells me that logrotate.timer calls logrotate.service on a daily base (and lists several other timers like plocate-updatedb.timer, anacron.timer, man-db.timer...)
Still OFFTOPIC ;).
Oh, thanks, I did not look this up. May be it works, because these entries are in files like (/etc/)cron.{hourly, daily, weekly, monthly, d}, which are "non-standard" cron directories for the original cron. The latter live in /var/spool/cron. But some things must be left out, otherwise it would make no sense to have cron disabled.
Quote from: hendrikL on 2024/05/28, 13:58:32
Same problem here, you have to downgrade systemd to 256-rc3-2!
How i did it,
First change in the boot command line that ro to rw (read only to read write), boot!
Kurze Frage:
Ich hab jetzt im grub ,,c" gedrückt und habe einen Prompt.
Aber wie ändere ich jetzt ,,ro" in ,,rw"?
@Isegrimm666:
Du hättest besser e für edit drücken sollen. Dann ro in rw ändern und F10 drücken.
edlin
@edlin:
Ich wollte eben meinen Post editieren (ja, es war die falsche Taste.
Nach der Änderung "ro" --> "rw" bootet das System wieder soweit.
Nächster Schritt wäre für mich:
Bootprozedur erstmal so weiter zu behalten, bis hier eine valide Lösung auftaucht. *g
Gerade mal eben ein doas apt update && doas apt upgrade gemacht:
[10:39:08][isegrimm@C-Y-G-N-A:~]$ doas apt upgrade
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
libgdal34t64 libpthread-stubs0-dev libqgis-app3.34.6 libqgis-native3.34.6 libqgispython3.34.6 libsnapd-glib-2-1 linux-image-6.7.12-amd64 samba-dsdb-modules
libkf5pulseaudioqt3 libqgis-3d3.34.6 libqgis-core3.34.6 libqgis-server3.34.6 libre2-10 libvpx8 linux-image-6.8.9-1-siduction-amd64 systemd-dev
libpoppler126t64 libqgis-analysis3.34.6 libqgis-gui3.34.6 libqgisgrass8-3.34.6 libsecp256k1-1 linux-headers-6.8.9-1-siduction-amd64 r-cran-teachingdemos
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Upgrading:
7zip evince-common gstreamer1.0-gl gstreamer1.0-x gvfs-libs libgoa-1.0-common libhwy1t64 libsmbclient0 python3-tornado samba-dsdb-modules yt-dlp
bolt fdisk gstreamer1.0-libav gtk-update-icon-cache libadwaita-1-0 libgstreamer-gl1.0-0 libldb2 libuuid1 r-cran-data.table samba-libs
bsdextrautils firefox gstreamer1.0-plugins-base gvfs libblkid1 libgstreamer-plugins-base1.0-0 libmalcontent-0-0 libwbclient0 r-cran-quantreg shared-mime-info
bsdutils firefox-l10n-de gstreamer1.0-plugins-good gvfs-backends libevdocument3-4t64 libgstreamer1.0-0 libmount1 mount r-cran-rsample switcheroo-control
easy-rsa firefox-l10n-en-gb gstreamer1.0-plugins-ugly gvfs-common libevview3-3t64 libgtk-3-0t64 libmsgraph-0-1 python3-ldb rfkill util-linux
eject gir1.2-gtk-3.0 gstreamer1.0-pulseaudio gvfs-daemons libfdisk1 libgtk-3-bin libsdl2-2.0-0 python3-pyproj samba-common util-linux-extra
evince gstreamer1.0-alsa gstreamer1.0-tools gvfs-fuse libgoa-1.0-0b libgtk-3-common libsmartcols1 python3-samba samba-common-bin uuid-runtime
Summary:
Upgrading: 71, Installing: 0, Removing: 0, Not Upgrading: 0
Download size: 111 MB
Space needed: 461 kB / 648 GB available
Continue? [J/n]
[10:39:48][isegrimm@C-Y-G-N-A:~]$
Sollte man es machen?
Also ich habs analog wie @charlyheinz gemacht. Den Link in /etc/systemd/system (tmp.mount -> /usr/share/systemd/tmp.mount) habe ich belassen, den zeitweise auskommentierten Eintrag für tmpfs in fstab habe ich wieder aktiviert.
Dann /usr/lib/systemd/system/tmp.mount nach /usr/share/systemd/tmp.mount kopiert.
edlin
@Isegrimm666: Was soll da passieren? Die Frage ist doch eher, warum kein full-upgrade?
edlin
@edlin
...weil das gestern zum hier diskutierten Problem führte. *g
Bitte Vorsicht mit dem (physischen) Kopieren der Datei nach /usr/share/systemd. Falls die Datei durch ein Paket aktualisiert wird, bekommt man dann davon "nichts mit", da dies mit an Sicherheit grenzender Wahrscheinlichkeit in /usr/lib/systemd passiert.
Besser ist es, auch in /usr/share/systemd "nur" einen symbolischen Link zu setzen - natürlich auf die physische Datei.
Noch besser ist es, die "hängenden" symbolischen Links einfach zu entfernen.
@edlin, @isegrimm666:
Ein "full-upgrade/dist-upgrade" ist seit der "Anpassung" bei mir wieder absolut unproblematisch - und irgendwann muß man es ja wieder machen ;).
Vielleicht sollte man aber die "-rc"-Varianten aussitzen.
@ro_sid:
Ich denke, das Aussitzen wäre wohl nicht das Verkehrteste.
Zum Verständnis:
Es juckt mich schon, Eure Anpassungen vorzunehmen und das Ganze zu fixen. Aber ich habe derzeit wenig Zeit und weiß, dass ich keine ruhige Minute hätte, bis ich - im Falle eines Misserfolgs - das ganze wieder 'hingebogen' habe.
Außerdem ginge das ohne Eure Mithilfe kaum und ich mag Euch einfach nicht andauernd auf den Keks gehen :)
Also Aussitzen ist blöd in diesem Falle ;)
Und wenn Du wieder booten kannst usw. warum nicht weiterhin das System aktuell halten mit 'apt full-upgrade', und wenn Zeit das Reparieren, genauer ausgedrückt, ins Lot bringen!
Mal 'nen Blick auf 'systemctl status tmp.mount' werfen wäre ein Anfang.
@ro_sid: Die hängenden Links werde ich noch in Ruhe aufräumen.
Das full-upgrade macht ja seit der t64 Aktion keine Probleme. Ich teste auch immer wieder, wie sich apt --solver 3.0 full-upgrade verhält; bisher waren die vorgeschlagenen Aktionen nachvollziehbar und IMHO unproblematisch.
@Isegrimm666: Du kannst ja die Anpassungen in Ruhe z. B. am WE machen. Die Ursache des Problems ist ja nun bekannt, ro_sid hat das ja weiter vorne erklärt. Bis dahin kannst du ja auf apt upgrade setzen. Allerdings musst du den Schritt eines full-upgrade über Kurz oder Lang gehen müssen. Mit dem Aussitzen ziehst du nur neue Probleme an Land.
Und was das ,,auf den Keks gehen" betrifft: Das Forum ist ja dazu da, sich auszutauschen und gegenseitig zu helfen. Zumal du ja auch noch das Glück hast, dass hier ein freundlicher Umgang herrscht.
edlin
könntest du das ein wenig ausführen .. bin grad unsicher was ich jetzt genau tun sollte :-X
Quote from: ro_sid on 2024/05/30, 10:53:39
Bitte Vorsicht mit dem (physischen) Kopieren der Datei nach /usr/share/systemd. Falls die Datei durch ein Paket aktualisiert wird, bekommt man dann davon "nichts mit", da dies mit an Sicherheit grenzender Wahrscheinlichkeit in /usr/lib/systemd passiert.
Besser ist es, auch in /usr/share/systemd "nur" einen symbolischen Link zu setzen - natürlich auf die physische Datei.
Noch besser ist es, die "hängenden" symbolischen Links einfach zu entfernen.
@ro-sid
Habe gerade mit meinem Zweitrechner ein apt-get dist-upgrade durchgeführt. Anschließend den Grub- Eintrag in rw geändert da auch hier der Rechner nicht mehr durchstartete.
Danach habe ich einen entsprechenden symbolischen Link auf die /usr/lib/systemd/system/tmp.mount in /usr/share/systemd/ tmp.mount angelegt.
Läuft!!
Quote from: hendrikL on 2024/05/30, 11:35:56
...
Mal 'nen Blick auf 'systemctl status tmp.mount' werfen wäre ein Anfang.
Was wäre da das wünschenswerte Ergebnis?
Mein system bootet, keine probleme mit systemd-256-rc3-5, nie ein /tmp eintrag in der fstab, fully upgraded
# systemctl status tmp.mount
Unit tmp.mount could not be found.Soll das so?
@michaa7
Kurz, ja, in deinem Falle!
Lang: Ich habe eine VM, dort ist es wie bei dir ohne fstab Eintrag, dann habe ich habe einen Arbeitslaptop, da ist tmp.mount aktiv und es hat einen fstab Eintrag und keinen symlink irgenwo hin.
siehe:
~$ ls -l /usr/lib/systemd/system/tmp.mount
-rw-r--r-- 1 root root 798 23. Mai 00:17 /usr/lib/systemd/system/tmp.mount
~$ LANG=C ls -l /usr/share/systemd/tmp.mount
ls: cannot access '/usr/share/systemd/tmp.mount': No such file or directory
fixed in git: https://salsa.debian.org/systemd-team/systemd/-/commit/a5ff99119a4b2ffc602d0fd97babeff1b5c23f69
Dann sollte es ja seinen Weg zu sid finden und wieder Ruhe sein.
edlin
Quote from: devil on 2024/05/30, 13:53:00
fixed in git: https://salsa.debian.org/systemd-team/systemd/-/commit/a5ff99119a4b2ffc602d0fd97babeff1b5c23f69
und laut deren diff wird nur der Link in /etc/... entfernt.
rm -f "$DPKG_ROOT/etc/systemd/system/tmp.mount"also
rm -f /etc/systemd/system/tmp.mountFür alle die Probleme mit dem Booten hatten sollte das die bevorzugte Lösung sein.
Wenn man nicht mit dem Tip von @hendrikL (rw) starten kann, dann von einem Life-System aus die Partition einhängen.
tested with a wintesky-iso
removed link from /etc
upgraded from 254.5-1 to 256rc3-5 (apt full-upgrade)
rebooted. all fine
@reddark
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.
Es sollte bereits genügen, wenn du den Link unterhalb von /etc ins Nirvana schickst. Danach sieht es bei mir so aus:
edlin@Devil:/etc/systemd/system$ systemctl status tmp.mount
tmp.mount - Temporary Directory /tmp
Loaded: loaded (/usr/lib/systemd/system/tmp.mount; enabled; preset: enabled)
Active: active (mounted) since Thu 2024-05-30 14:17:10 CEST; 12min agoedlin
System bootet
Bingo :D
Thanks to all !!
@edlin: habs so gemacht und trotzdem siehts so aus :-X
systemctl status tmp.mount
● tmp.mount - Temporary Directory /tmp
Loaded: loaded (/usr/lib/systemd/system/tmp.mount; enabled; preset: enabled)
Active: active (mounted) since Thu 2024-05-30 14:40:02 CEST; 1min 50s ago
Invocation: 27a857dd681c4b84bc77f509368138b2
Where: /tmp
What: tmpfs
Docs: https://systemd.io/TEMPORARY_DIRECTORIES
man:file-hierarchy(7)
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
Tasks: 0 (limit: 38092)
Memory: 4.0K (peak: 2.2M)
CPU: 5ms
CGroup: /system.slice/tmp.mount
Mai 30 14:40:02 laptop1 systemd[1]: Mounting tmp.mount - Temporary Directory /tmp...
Mai 30 14:40:02 laptop1 systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
@reddark
Alles gut, ist in Ordnung, das darf ruhig laufen!
fein :-*
Quote from: edlin on 2024/05/30, 14:32:07
@reddark
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.
Es sollte bereits genügen, wenn du den Link unterhalb von /etc ins Nirvana schickst. Danach sieht es bei mir so aus:
edlin@Devil:/etc/systemd/system$ systemctl status tmp.mount
tmp.mount - Temporary Directory /tmp
Loaded: loaded (/usr/lib/systemd/system/tmp.mount; enabled; preset: enabled)
Active: active (mounted) since Thu 2024-05-30 14:17:10 CEST; 12min ago
edlin
System bootet
Ich habe gerade eben Edlins Ablauf nachgestellt (allerdings den Symlink unter /etc/systemd/system/ vorher gekillt ... danach wollte ich den 2. Link auch killen, aber der war nicht mehr da.)
Dann ein apt full-upgrade ... Neustart ...
... und das System lief 1a.
Kurz einen Test gemacht:
[15:14:41][isegrimm@C-Y-G-N-A:~]$ systemctl status tmp.mount
● tmp.mount - /tmp
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Thu 2024-05-30 15:10:16 CEST; 4min 50s ago
Invocation: 4447ddadd0324fef88320cb28585df2f
Where: /tmp
What: tmpfs
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 18910)
Memory: 4.0K (peak: 768.0K)
CPU: 5ms
CGroup: /system.slice/tmp.mount
Mai 30 15:10:16 C-Y-G-N-A systemd[1]: Mounting tmp.mount - /tmp...
Mai 30 15:10:16 C-Y-G-N-A systemd[1]: Mounted tmp.mount - /tmp.
Danke.
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:
Quotetmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
auskommentiert und anschließend ein DU durchgeführt- voila, alles läuft.
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?
nun. rm -f /etc/<foo>
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.
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
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
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. :)
Quote from: mdmarmer on 2024/05/31, 02:32:45
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.
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.
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.
@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".
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"?
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. :)
Quote from: michaa7 on 2024/05/31, 11:13:20
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.
Quote from: harley-peter on 2024/05/31, 11:22:21
Vielen Dank an alle, das war hervorragende Community-Arbeit. :)
Schön gebrüllt Löwe, da schließe ich mich gerne an! :)
Quote from: harley-peter on 2024/05/31, 11:22:21
Vielen Dank an alle, das war hervorragende Community-Arbeit. :)
+1
Thanks to all the community for the help to work out this little challenge.
@ro_sid
Quote from: ro_sid on 2024/05/30, 02:19:00
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.
Quote from: ro_sid on 2024/05/31, 11:04:53
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.
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
Quote from: scholle1 on 2024/05/31, 14:41:37
@ro_sid
Quote from: ro_sid on 2024/05/30, 02:19:00
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 :).
Quote from: scholle1
Quote from: ro_sid on 2024/05/31, 11:04:53
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 ;).
Quote from: michaa7 on 2024/05/31, 11:13:20
... 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.
Quote from: harley-peter on 2024/05/31, 11:22:21
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. :)
Thanks dibl.
Quote from: dibl on 2024/05/31, 15:45:15
...
Semi-answer: This tmpfs for /tmp mount line goes back to the days when SSDs were new technology,...
I assume today it is deprecated ?
Quote from: dibl on 2024/05/31, 15:45:15
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.
Quote from: michaa7 on 2024/05/31, 22:10:47
Thanks dibl.
Quote from: dibl on 2024/05/31, 15:45:15
...
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.
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)?
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.
Quote from: hendrikLNow 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. :(
Quote from: hendrikL on 2024/06/01, 08:23:39
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.
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?
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
Danke ... dann bin ich ja soweit safe.
*verinnerlicht man apt ;)
Quote from: michaa7 on 2024/05/31, 22:10:47
Thanks dibl.
Quote from: dibl on 2024/05/31, 15:45:15
...
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
Quote from: dibl on 2024/06/01, 15:59:45
...
It looks to me like the answer is "YES", for Debian Linux.
...
thanks dibl, especially for the two links on which your answer seems to be based upon. What's written there seams exhaustive and -in short- confirms that
A) fstab entry for /tmp *is* unneccessary for modern OS and modern SSDs since 2012
B) in 2012 /tmp mount to tmpfs was considered a hack usefull only if you knew what you did and why exactly you did it.
So the summery, at least for me, now is:
- The fstab entry was not the cause of the problem, but if it was nontheless, delete it ... you don't need it.
- It this entry is there and you don't know what to do with it because there is no problem ... throw dice and act accordingly ;D
- The ones hit by the broken systemd link now know via this thread how to repair their system. All the others are fine now because the newer systemd postinstall scripts checks for the existens of the broken link and delete it.
I assume this catches the state of the problem. If not ... correct me with a better version.
Quote from: dibl on 2024/06/01, 15:59:45
[...]
This is also very interesting (to me) and relevant to our subject:
https://lists.debian.org/debian-devel/2012/06/msg00311.html
With all these "old" arguments, tmp.mount must be a really bad idea :), as it accomplishes just that.
Quote from: ro_sid on 2024/06/01, 20:22:39
With all these "old" arguments, tmp.mount must be a really bad idea :), as it accomplishes just that.
:D Apparently, Serge lost the vote!
https://systemd.io/TEMPORARY_DIRECTORIES/
With the update to systemd 256~rc3-7 I have the following error with java:
library initialization failed - unable to allocate file descriptor table - out of memory
towo linked to this workaround in 2018:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917167#37
Many thanks!