Festplatte plötzlich 0Byte frei ?!?

[Starfoxfs]

Hi zusammen,

Ich habe heute mein Suse 11.3 am laufen gehabt, und habe plötzlich 0Byte auf der Festplatte frei und das System crashed.

Nach neuestem Stand fährt mein Suse jetzt im Failsafe garnicht mehr hoch und im Normal Modus fährt es nur in den Runlevel 3 hoch weil Runlevel 5 failed.

Was ich in letzter Zeit gemacht habe war dem Mülleimer mit dem Dateimanager kein Größenbegrenzung mehr festgelegt da mich das immer wenn ich Dateien gelöscht habe nervte.

Im Mülleimer selbst sind aber keine Daten mehr vorhanden, normalerweise dürfte Platz auf der Platte sein.

[gropiuskalle]

Jage erst mal ein fsck auf die Partition(en) los, dann weißt Du hoffentlich mehr. Interessant währe aber zumindest, wo genau der boot-Vorgang abbricht.

[nopes]

ansonsten kannst du mit "du" und "df" mal schauen, wo der Platz gefressen wird.

[Starfoxfs]

beim Failsafe Mode hält das System bei fsck clean ...bytes ...bytes

beim normalen Startvorgang hält das System bei Runlevel 5 failed

und dann kommt noch FIBMAP oder sowas in die Richtung fehlgeschlagen ...

[gropiuskalle]

Schreibe die Meldungen doch besser mal im Wortlaut ab.

[Aqualung]

Starte mal ein Live-Linux (Knoppix, Suse-rescue ...) und prüfe die Partitionen von da.

[Dodobo.reloaded]

Der Befehl zum Checken des Platzes von deinem installierten System aus lautet exakt z.B. so - als root:


df -h
du -x --max-depth=2 / 2>/dev/null | sort -nr | head -n30

Das zeigt dir die 30 verschwenderischsten Verzeichnisse an (nur auf dieser Partition). Als root hat man ja eigentlich noch 5% Reserve, einstellbar mit tune2fs. Es gibt doch bestimmt auch bei SuSE einen Befehl, um die zwischengespeicherten Pakete zu löschen? Oder notfalls Dateien in /tmp, die schon mehr als 1-2 Tage alt oder nur große Videos/ Flashdateien sind.

Dazu drückst du notfalls, falls du an keine Eingabemöglichkeit kommst, STRG + ALT + F1 und loggst dich dann dort als root ein, alternativ z.B. bei F2.

Auf einer Live CD musst du das "-x" bei du weglassen. Die größten Dateien auf deinen Partitionen werden dann trotzdem gefunden, allerdings auch die im /home, also wenn du da große Videos hast. Dann ersetze "head -n30" durch "less" und scrolle durch alles durch oder exludiere /home, also so:


du --max-depth=2 --exclude='/home' / 2>/dev/null | sort -nr | head -n30

2>/dev/null ist nur dazu da, damit nicht einige Zugriffsverweigerungen in /proc (auch als root) die 30 Zeilen, die angezeigt werden sollen, auf weniger sinnvolle Zeilen reduzieren. Damit werden einfach alle Fehlermeldungen in den Mülleimer umgeleitet. ;)

[gropiuskalle]

Es gibt doch bestimmt auch bei SuSE einen Befehl, um die zwischengespeicherten Pakete zu löschen?

/tmp wäre theoretisch wirklich ein Kandidat, da SuSE dessen Inhalt per default niemals löscht. Um /tmp beim booten zu löschen: /etc/sysconfig/cron als root mit einem Editor öffnen und in der Zeile


CLEAR_TMP_DIRS_AT_BOOTUP="no"

das "no" zu "yes" editieren.

Allerdings passen die beschriebenen Symptome nicht ganz auf ein übervolles /tmp.

[Dodobo.reloaded]

http://linux.derkeiler.com/Mailing-Lists/SuSE/2009-01/msg02066.html

Hier steht noch, wie man die ganzen zwischengespeicherten Pakete löscht. Die braucht man nur, wenn man mal eine Software reinstalliert. Dann spart man sich den automatischen Download aus dem Internet.

Bei Debian/ Ubuntu geht das mit einem Befehl - dort ist für SuSE auch einer (zypper) angedeutet. Aber manuelles Löschen ist zumindest bei Ubuntu theoretisch möglich.

Die Ursache sollte aber gefunden werden, davor oder danach. Z.B. überlaufende, mehrere GB große Logfiles, wenn irgendwas Amok-geloggt wird. ;)

[gropiuskalle]

Hier steht noch, wie man die ganzen zwischengespeicherten Pakete löscht. Die braucht man nur, wenn man mal eine Software reinstalliert. Dann spart man sich den automatischen Download aus dem Internet.

Ach darauf beziehst Du Dich. Ich glaube nicht, dass der zypper cache besonders viel Lösungspotential bietet:


kalle@hoppers:~> du -h /var/cache/zypper/RPMS
79M /var/cache/zypper/RPMS

Man könnte jetzt noch weiter spekulieren, was genau die Platte zugemüllt hat oder ob nicht doch irgendein anderer Grund anzunehmen ist, aber das bringt wenig. Starfoxfs hat auf jeden Fall genug Anregungen erhalten. Warten wir mal ab, was er zwischenzeitlich herausfindet.

[heatwalker]

Ich tippe mal auf die

.xsession-errors
unterhalb des home Verzeichnisses.

würde ich auf jedenfall kontrollieren. :)

[Dodobo.reloaded]

Ach darauf beziehst Du Dich. Ich glaube nicht, dass der zypper cache besonders viel Lösungspotential bietet:

79 MB reichen bestimmt dicke, damit sein System wieder mehr als 0 Byte hat, um durchstarten zu können. ;)

Aber im Link steht auch, dass bei SuSE per default nix drin sei (damals jedenfalls).

[nopes]

wie wäre es, wenn ihr mal würdet, bis der Eigner sich wieder meldet, mal nur so als Einwurf, nicht das ich euch bremsen will;)

[gropiuskalle]

Ja, wie gesagt: man könnte jetzt noch seitenlang weiterspekulieren, aber die Kooperation mit dem Ersteller eines threads ist doch eigentlich ein recht bewährtes Prinzip. Also erst mal schauen, was Starfoxfs so zu sagen hat.

[Dodobo.reloaded]

Hallo nopes,


wie wäre es, wenn ihr mal würdet
Ich würde gern warten, auch warten würden, aber "würden" würde ich nicht. :D

Gegen die Langeweile und als Erinnerung:

yes warten | xargs

[nopes]

Hallo nopes,

Zitat:
wie wäre es, wenn ihr mal würdet
Ich würde gern warten, auch warten würden, aber "würden" würde ich nicht.

Gegen die Langeweile und als Erinnerung:
Zitat:
yes warten | xargslol - erwischt ;)

[Starfoxfs]

So also ich bin weiter gekommen :D

ich habe im Runlevel 3 ein paar meiner Meinung nach unwichtigen log Dateien in /var/log gelöscht und den /tmp/ Ordner geleert.

Danach lies sich Suse wenigstens wieder im Failsafe Mode hochfahren.

Dann habe ich dem Mülleimer per Dolphin wieder eine feste Größe von 1,97GB zugewiesen und die wohl nicht unerhebliche Menge die sich noch im Papierkorb befand gelöscht.

Jetzt sagt mir df -h :


Filesystem Size Used Avail Use% Mounted on
/dev/md126p2 20G 3.8G 15G 21% /
devtmpfs 991M 236K 991M 1% /dev
tmpfs 992M 4.0K 992M 1% /dev/shm
/dev/md126p3 208G 22G 176G 11% /home

vorher sah es so aus:


Filesystem Size Used Avail Use% Mounted on
/dev/md126p2 20G 20G 0G 100% /
devtmpfs 991M 236K 991M 1% /dev
tmpfs 992M 4.0K 992M 1% /dev/shm
/dev/md126p3 208G 22G 176G 11% /home

sprich die Home Partition war bis zum Anschlag voll.

Kann man die Home Partition eigentlich nachträglich mit dem Partitionsmanager vergrößern ??

Ich mach nun erstmal ne Datensicherung :eek:

Ob das System nun im Normal Modus wieder hochfährt muss ich erst noch schauen werde euch aber berichten...

[craano]

Jetzt sagt mir df -h :


Filesystem Size Used Avail Use% Mounted on
/dev/md126p2 20G 3.8G 15G 21% /
devtmpfs 991M 236K 991M 1% /dev
tmpfs 992M 4.0K 992M 1% /dev/shm
/dev/md126p3 208G 22G 176G 11% /home

vorher sah es so aus:


Filesystem Size Used Avail Use% Mounted on
/dev/md126p2 20G 20G 0G 100% /
devtmpfs 991M 236K 991M 1% /dev
tmpfs 992M 4.0K 992M 1% /dev/shm
/dev/md126p3 208G 22G 176G 11% /home

sprich die Home Partition war bis zum Anschlag voll.
...

Es war wohl eher /dev/md126p2 vollgelaufen. Home liegt doch woanders.
Partionen zu resizen geht, birgt aber die Gefahr eines Datenverlusts. Also Backup ist angesagt.
Du hast auf md126p3 doch noch viel Platz. Da muss ja nicht nur /home allein residieren. Die von dir ermittelten Speicherfresser /tmp und /var/log könntest Du auch dorthin verbannen. Mit
mount -o bindkannst Du die beiden Ordner ja wieder an die richtige Stelle im System bringen. Dann bräuchtest Du keine Partitioen verändern.
Also in einem Rettungssystem au mkd126p3 die drei Ordner home, tmp, und log erstellen. Alle Dateien hineinkopieren (cp -a) und dann in der /ets/fstab entsprechende bind-mounts einfügen. Neu booten. Fertig.

...und vielleicht mal schauen vonwelchem Dienst diese riesigen Log-Halden stammen.

Grüße.
craano

[nopes]

Hi,

zum ändern von Partition gibt es parted bzw. gparted (wesentlich leichter).
Wie auch immer du solltest die Daten natürlich sichern, bevor du das machst, sowie ich es sehe hast bzw. solltest du /home kleiner und / größer, oder direkt eine eigene Partition für /tmp und/oder /var erstellen.

[Starfoxfs]

Es war der Mülleimer,
nicht die /tmp bzw /var/log Verzeichnisse.

Dadurch das ich dem Mülleimer keine Speicherbegrenzung mehr gegeben hatte wurden dort einige Daten reinverfrachtet und das löste dann den Systemcrash aus.

Das System bootet inzwischen auch wieder im Normal Modus, und läuft auch wieder stabil ;)

Big thx an alle :)

[nopes]

Hi,

ich hatte das auch nicht gesagt, weil ich da die Probleme gesehen habe, Partitionierung ist ja Geschmackssache - das ist auch gut so! Jedenfalls ist es durch aus normal /tmp und /var in eigenen Bereichen zu halten, die Gefahr einer DOS Attacke wird so kleiner (das war ja eine, auch wenn du selber dafür zuständig gewesen bist ;)).