expertenaustausch > linux.debian.user.german

Klaus Becker (07.02.2020, 11:30)
Moin,

nach einem Stromausfall gestern abend habe ich heute morgen ein Bootproblem.

Debian unstable startet zwar, aber nur im Textmodus, und wenn ich in tty
als Benutzer "startxfce4" oder als root "startx" eingebe, bekomme ich u.
A. folgende Meldung:

Fatal server error:
(EE) Could not creat lock file in /tmp/.tX1-lock
xinit:giving up

Wenn ich versuche, mein System zu aktualisieren, bekomme ich:

chmod 0700 of directory /var/lib/apt/...
failed (30:Dateisystem nicht beschreibbar)

Daraufhin habe ich beim Neustart in grub in der Linie, wo "Linux" steht,
"ro" durch "rw" ersetzt, und siehe da, mein System startet normal, und
ich benutze es im Moment.

Habe ich damit ein Sicherheitsproblem?

Was kann ich machen, damit Debian wieder ohne händisches Eingreifen
normal startet?

Sind "chmod 01777 /tmp" und "chmod 01777 /var/tmp" richtig? Das habe ich
mir mal notiert, frage aber lieber erst nach.

schönen sonnigen Tag wünscht

Klaus
Ulf Volmer (07.02.2020, 12:20)
On 07.02.20 10:30, Klaus Becker wrote:

> nach einem Stromausfall gestern abend habe ich heute morgen ein
> Bootproblem.


> Daraufhin habe ich beim Neustart in grub in der Linie, wo "Linux" steht,
> "ro" durch "rw" ersetzt, und siehe da, mein System startet normal, und
> ich benutze es im Moment.


Würde ich von Abraten. Mach ein fsck auf alle beteiligten Filesysteme.
Im Zweifel von einem Live- Medium wie grml oder ähnlich.

> Sind "chmod 01777 /tmp" und "chmod 01777 /var/tmp" richtig? Das habe ich
> mir mal notiert, frage aber lieber erst nach.


Die führende 0 ist überflüssig.

Viele Grüße
Ulf
Klaus Becker (07.02.2020, 13:00)
Le 07/02/2020 à 11:11, Ulf Volmer a écrit :
> On 07.02.20 10:30, Klaus Becker wrote:
> Würde ich von Abraten. Mach ein fsck auf alle beteiligten Filesysteme.
> Im Zweifel von einem Live- Medium wie grml oder ähnlich.


Hab' ich gemacht,das System ist "clean".

>> Sind "chmod 01777 /tmp" und "chmod 01777 /var/tmp" richtig? Das habe ich
>> mir mal notiert, frage aber lieber erst nach.

> Die führende 0 ist überflüssig.
> Viele Grüße
> Ulf


Habe obige Befehle von Knoppix aus ausgeführt, neugestartet: alles in
Butter.

danke für die Antwort

Klaus
Christian Knoke (08.02.2020, 12:10)
Klaus Becker schrieb am 07. Feb um 11:59 Uhr:
> Le 07/02/2020 à 11:11, Ulf Volmer a écrit :
> Hab' ich gemacht,das System ist "clean".


Das reicht meiner Erfahrung nach in dieser Situation nicht immer aus.

Durch das "rw" in der Linux-Zeile wird das rw-mounten erzwungen, auch wenn,
wie in deinem Fall, Filesystem- oder Journalfehler drinnen sind. Das
initrd-System, das als erstes gestartet wird, kann dann aber das root-System
nicht mehr checken, eben weil es schreibbar gemountet wurde. Lediglich das
Journal wird abgearbeitet. Danach wird das "clean"-Flag gesetzt.

Durch den Stromausfall können aber trotzdem (zusätzlich) Dateisystemfehler
vorhanden sein, die unentdeckt bleiben, weil du die Dateisystemprüfung
umgangen hast.

Deshalb solltest du die Prüfung erzwingen, bei einem ext[234] System mit

# fsck.ext4 -v -f ROOTDEVICE

Sinnvollerweise geschieht das von einem Rettungssystem aus, wie Ulf Volmer
geschrieben hat.

Vergiss auch nicht, die linux Zeile wieder auf ro zurückzusetzen, auch wenn
es dir in diesem Fall nicht mehr hilft.

> > > Sind "chmod 01777 /tmp" und "chmod 01777 /var/tmp" richtig? Das habe ich
> > > mir mal notiert, frage aber lieber erst nach.


Hier habe ich eine Frage: vor einigen Jahren war es üblich, /tmp und
/var/tmp in den RAM zu legen. Debian 9 und 10 machen das aber nicht mehr.
Gibt es dafür gute Gründe, oder macht man das nur, weil alle jetzt SSDs haben
und es nicht mehr vorteilhaft erscheint?

> Habe obige Befehle von Knoppix aus ausgeführt, neugestartet: alles in
> Butter.
> danke für die Antwort
> Klaus


Gruß
Christian
Jochen van Geldern (08.02.2020, 13:40)
Am Sat, 8 Feb 2020 11:00:09 +0100
schrieb Christian Knoke <chrisk>:

> Hier habe ich eine Frage: vor einigen Jahren war es üblich, /tmp und
> /var/tmp in den RAM zu legen. Debian 9 und 10 machen das aber nicht
> mehr. Gibt es dafür gute Gründe, oder macht man das nur, weil alle
> jetzt SSDs haben und es nicht mehr vorteilhaft erscheint?


Hallo Christian,
Das es üblich war /tmp in Ramdisk (tmpfs) abgelegen war damals üblich
wenn genug RAM-Speicher vorhanden war.
Aber es macht heute immer noch Sinn /tmp und /run in tmpfs abzulegen:
1. Ist der Perfomenze-Unterschied noch nicht zu vernachlässigen trotz
SSD und co. RAM ist immer noch schneller als Flash.
2. Du schonst die SSD, da in solch ein Verzeichnis am meisten
Geschieben wird.
3. Soll diese Verzeichnisse beim Booten immer Leer sein, sonst kann es
zu Probleme kommen. Wenn die auf tmpfs liegen passiert das immer
und Zuverlässig Automatisch, sonst müssen die immer Leer Gelöscht
werden. Was Passiert wenn das durch ein Fehler beim Booten unterbleibt?

Aber der Inhalt von /var/tmp sollte ein Neustart immer überleben, da
teilweise Daten gespeichert werden die, z.B. zur Wiederherstellung von
nicht gespeicherten Dokumenten dienen.
Manfred Schmitt (08.02.2020, 20:20)
Jochen van Geldern schrieb:

> Aber es macht heute immer noch Sinn /tmp und /run in tmpfs abzulegen:
> 1. Ist der Perfomenze-Unterschied noch nicht zu vernachlässigen trotz
> SSD und co. RAM ist immer noch schneller als Flash.
> 2. Du schonst die SSD, da in solch ein Verzeichnis am meisten
> Geschieben wird.
> 3. Soll diese Verzeichnisse beim Booten immer Leer sein, sonst kann es
> zu Probleme kommen. Wenn die auf tmpfs liegen passiert das immer


Das hoere ich zum ersten mal, was denn für Probleme?
Mein /tmp ist ganz sicher beim boot nie leer.
Und direkt nachdem der fsck aus der initramfs lief ist /run
auch nicht mehr leer :-)

Und wech,
Manne
Jochen van Geldern (08.02.2020, 21:10)
Am Sat, 8 Feb 2020 18:43:13 +0100
schrieb Manfred Schmitt <expires-200331>:

> Jochen van Geldern schrieb:
> Das hoere ich zum ersten mal, was denn für Probleme?
> Mein /tmp ist ganz sicher beim boot nie leer.


Schaue mal in:


Es muss nicht unbedingt Probleme auftreten. Aber nach abstürze können
schon Dateien in /tmp zurückbleiben, die dessen exiestens Fehlfunktionen
verursachen können. Deswegen ist es besser /tmp als ersten (!) beim
Booten leer zu löschen.
Aber /tmp sollte nur für temporäre Dateien
benutzt werden. Wenn beim Boot Dateien dort existieren, werden die von
Anwendungen beim Booten schon angelegt.

> Und direkt nachdem der fsck aus der initramfs lief ist /run
> auch nicht mehr leer :-)


Nun fsck ist eine Anwendung die bei Booten gestartet wird.
Klaus Becker (09.02.2020, 11:40)
Le 08/02/2020 à 11:00, Christian Knoke a écrit :
> Klaus Becker schrieb am 07. Feb um 11:59 Uhr:
>> Le 07/02/2020 à 11:11, Ulf Volmer a écrit :
>>> On 07.02.20 10:30, Klaus Becker wrote:


....
[..]
> geschrieben hat.
> Vergiss auch nicht, die linux Zeile wieder auf ro zurückzusetzen, auch wenn
> es dir in diesem Fall nicht mehr hilft..


Gestern hatte ich wieder das gleiche Problem, und es war mit "chmod 1777
/tmp" nicht mehr zu lösen.

Da habe ich fsck.ext4 von Knoppix aus ausgeführt, laut fsck alles
"clean". Dann hab ich's nochmal mit der Option -p gemacht und dadurch
eine automatische Reparatur des Dateisystems erzwungen.

Hat zwar nichts gemacht, danach startet Debian aber wieder problemlos.

Gruß

Klaus
Christian Knoke (09.02.2020, 14:10)
Hallo Klaus,

Klaus Becker schrieb am 09. Feb um 10:40 Uhr:
> Le 08/02/2020 à 11:00, Christian Knoke a écrit :
> > Klaus Becker schrieb am 07. Feb um 11:59 Uhr:
> > > Le 07/02/2020 à 11:11, Ulf Volmer a écrit :
> > > > On 07.02.20 10:30, Klaus Becker wrote:


> Gestern hatte ich wieder das gleiche Problem, und es war mit "chmod 1777
> /tmp" nicht mehr zu lösen.
> Da habe ich fsck.ext4 von Knoppix aus ausgeführt, laut fsck alles "clean".
> Dann hab ich's nochmal mit der Option -p gemacht und dadurch eine
> automatische Reparatur des Dateisystems erzwungen.
> Hat zwar nichts gemacht, danach startet Debian aber wieder problemlos.


Wichtig ist die Option -f zu fsck.ext4 . Ohne -f wird bei einem Dateisystem
mit gesetztem "clean" Flag nichts gemacht.

Gruß
Christian
Christian Knoke (09.02.2020, 15:30)
Hallo Jochen,

Jochen van Geldern schrieb am 08. Feb um 12:28 Uhr:
[..]
> Aber der Inhalt von /var/tmp sollte ein Neustart immer überleben, da
> teilweise Daten gespeichert werden die, z.B. zur Wiederherstellung von
> nicht gespeicherten Dokumenten dienen.


ich habe jetzt nach

$ aptitude install initscripts
$ man tmpfs
$ joe /etc/fstab
$ update-initramfs -u

tmpfs /tmp tmpfs size=128M,mode=1777

in /etc/fstab und schau mal obs Probleme gibt.

Die manpage von tmpfs [1] ist in das Paket initscripts ausgelagert worden.
Sollte das ein Hinweis darauf sein, das es mit (dem laufenden) systemd +
tmpfs zu Problemen kommt?

Gruß
Christian

[1]
Jochen van Geldern (09.02.2020, 17:40)
Am Sun, 9 Feb 2020 14:21:07 +0100
schrieb Christian Knoke <chrisk>:

[..]
> Die manpage von tmpfs [1] ist in das Paket initscripts ausgelagert
> worden. Sollte das ein Hinweis darauf sein, das es mit (dem
> laufenden) systemd + tmpfs zu Problemen kommt?

Leider Benutze ich kein systemd und habe mich auch nicht drin eingearbeitet.
Nun ich benutze Gentoo Linux, welches immer noch sysvinit mit openrc als
Standard Initsystem benutzt. Man kann zwar Gentoo-Linux auf systemd
umstellen, aber ich habe noch keine Notwendigkeit gesehen das zu machen.
Ähnliche Themen