Nach Verbesserung mit
Code: [Auswählen]
touch /etc/systemd/system/tmp.mount
You have overwritten the dead link to /usr/share/.. with this.
und
Code: [Auswählen]
systemctl unmask tmp.mount
schien alles Tutti zu sein.
Während eines neuerlichen Neustarts stockte boot unter
{ OK ] Reaches target graphical.target - Graphical Interface.
Starting systemd-update-utmp-runlie?- Record RunlevelChange in UTMP . . .
[ OK ] Finished systemd-update-ut,mp-runle?e - Record Runlevel Change in UTMP . . .
4.186589 Bluetooth: hc10: Malformed MSFT vendor event: 0x02
4.200611 Bluetooth: hc10: Reading supported features failed (-16)
>ab da ging es nicht mehr weiter<.
Wie kann man boot beenden ?
Gruß solo
Ich weiß nicht, was Du da machst!
Schritt für Schritt bitte folgen, es ist erst mal aufräumen angesagt!
- als root -> 'rm /etc/systemd/system/tmp.mount'
- reboot des systems -> wenn nötig in der cmd-Zeile ro nach rw ändern -> siehe https://forum.siduction.org/index.php?topic=9357.msg74409#msg74409 <- wenn es normal bootet bitte nichts ändern, nur im Falle es bootet nicht!
- kurz berichten, hat es normal gebootet oder mußte ro nach rw geändert werden, kurz, keine Romane, kein Fettdruck!
- die Ausgabe von 'systemctl status tmp.mount' hier Pasten, alles!
- die Ausgabe von 'cat /etc/fstab' hier rein, komplett.
- auf Antwort warten, nichts unüberlegtes tun!
Wie beschrieben stockt boot und ich komme nicht mehr zur Konsole, schaut schlimm aus.
Quote from: solo on 2024/05/31, 17:54:48
Wie beschrieben stockt boot und ich komme nicht mehr zur Konsole, schaut schlimm aus.
du kannst aber im grub boot auswahlmenü "e" (für edit) drücken und in der zeile des kernel startcommands "ro" nach "rw" ändern wie bereits erwähnt.
Ich konnte im grub boot auswahlmenü "e" (für edit) [statt enter] drücken und in der zeile des kernel startcommands "ro" nach "rw" ändern und mit F10 siduction aufrufen.
.
# systemctl status tmp.mount
Unit tmp.mount could not be found.
# cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=A0A4-3116 /boot/efi vfat umask=0077 0 2
UUID=c5183c51-8a58-4309-9899-c2b7a90285f3 / ext4 defaults,noatime 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Die tmpfs Zeile ist unschädlich.
Gib bitte eimal die Ausgabe von
apt policy systemd
und
ls -l /usr/share/systemd/tmp.mount
und
ls -l /usr/lib/systemd/system/tmp.mount
Die Lösung und Vorgehensweise steht vollständig in https://forum.siduction.org/index.php?topic=9357.0 (https://forum.siduction.org/index.php?topic=9357.0)
hauptsächlich Seite 5-8.
# apt policy systemd
systemd:
Installiert: 256~rc3-7
Installationskandidat: 256~rc3-7
Versionstabelle:
*** 256~rc3-7 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
# ls -l /usr/share/systemd/tmp.mount
ls: Zugriff auf '/usr/share/systemd/tmp.mount' nicht möglich: Datei oder Verzeichnis nicht gefunden
# 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
Existiert denn noch die unsägliche /etc/systemd/system/tmp.mount?
ls -l /etc/systemd/system/tmp.mount
Wenn ja, dann rm -f /etc/systemd/system/tmp.mount
Erklärungen findest du im anderen Thread.
edlin
Quote from: solo on 2024/06/01, 11:20:33
# systemctl status tmp.mount
Unit tmp.mount could not be found.
# cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=A0A4-3116 /boot/efi vfat umask=0077 0 2
UUID=c5183c51-8a58-4309-9899-c2b7a90285f3 / ext4 defaults,noatime 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Bitte die Zeile 'tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0' mit einem '#' auskommentieren! reboot und alles sollte gut sein!
Quote from: hendrikL on 2024/06/02, 11:21:49
Quote from: solo on 2024/06/01, 11:20:33
# systemctl status tmp.mount
Unit tmp.mount could not be found.
# cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=A0A4-3116 /boot/efi vfat umask=0077 0 2
UUID=c5183c51-8a58-4309-9899-c2b7a90285f3 / ext4 defaults,noatime 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Bitte die Zeile 'tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0' mit einem '#' auskommentieren! reboot und alles sollte gut sein!
Wirklich? Angesichts von
QuoteUnit tmp.mount could not be found.
.
Quote from: solo on 2024/06/02, 09:34:53
# apt policy systemd
systemd:
Installiert: 256~rc3-7
Installationskandidat: 256~rc3-7
Versionstabelle:
*** 256~rc3-7 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
# ls -l /usr/share/systemd/tmp.mount
ls: Zugriff auf '/usr/share/systemd/tmp.mount' nicht möglich: Datei oder Verzeichnis nicht gefunden
# 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
Dort steht, dass das Verzeichnis nicht gefunden wurde, also /usr/share/...
Welches auch richtig ist, dies darf genauer gesagt sollte dort nicht sein!
Um die Verwirrung nicht noch grösser zu machen, einfach die tmp Zeile in der fstab auskommentieren, das reicht.
Andere Möglichkeit wäre tmp.mount wieder zu aktivieren.
Beides ginge!
Danke für die Klarstellung.
Ich hab' zwar immer noch nicht ganz kapiert warum /usr/share/systemd überhaupt eine Rolle spielt, wenn es nicht in /etc/systemd referenziert wird, andererseits (/usr)/lib/systemd/system/tmp.mount aber installiert ist.
Aber wenn es so klappt :) ... soll es mir recht sein.
Mh, das war der Tote link von /etc.
Scholle1 hat irgendwo im Nachbar Thread beschrieben was da vermutlich passiert ist, bzw was geschehen war.
Quote from: ro_sid on 2024/06/02, 17:38:52
Ich hab' zwar immer noch nicht ganz kapiert warum /usr/share/systemd überhaupt eine Rolle spielt, wenn es nicht in /etc/systemd referenziert wird, andererseits (/usr)/lib/systemd/system/tmp.mount aber installiert ist.
Ja das ist verwirrend.
Der Fehler war bereits in systemd-256~rc2-1vorhanden.
tmp.mount in /usr/share/systemd und der Link /etc/systemd/system/tmp.mount darauf.
1. Wenn in /usr/share/systemd , dann gehört es genau in /usr/share/systemd/<user>/ . Weil für User Units.
2. Vermutung: Der Entwickler hat zwei Versionen von tmp.mount gehabt und mittels des Link unter /etc die Auswahl getroffen.
3. Diese verhunzte Kombination tmp.mount in /usr/share/systemd und Link unter /etc hat es irgenwie in systemd-256~rc2-1 geschafft.
4. In systemd-256~rc3-5 ist es aufgefallen und tmp.mount wurde dorthin verschoben, wo es hingehört, nämlich nach /usr/lib/systemd/system/. Der Link wurde dabei übersehen oder vergessen.
5. Jetzt hatten wir das boot Problem.
Die Lösung ist nach wie vor die gleiche. Mit ls -l prüfen ob die
Datei /usr/lib/systemd/system/tmp.mount vorhanden ist. Es darf kein Link sein. Wenn ja, dann /etc/systemd/system/tmp.mount löschen und
systemctl daemon-reload ausführen. systemd-256~rc3-6 macht es mittels des eingepfegten Patch.
Das Verzeichnis /usr/share/systemd/<user>/ soll für User Units sein. Zum Beispiel wenn du Software im /home Verzeichnis installierst und für deren Funktion eine Unit anlegst.
Quote from: scholle1 on 2024/06/03, 12:32:41
...
4. In systemd-256~rc3-5 ist es aufgefallen und tmp.mount wurde dorthin verschoben, wo es hingehört, nämlich nach /usr/lib/systemd/system/. Der Link wurde dabei übersehen oder vergessen.
5. Jetzt hatten wir das boot Problem.
...
Das boot Problem existierte ab 256~rc3-
3