mit df / falscher Wert

odigo

odigo

0
Hi zusammen,

ich habe ein riesiges Problem beim Starten meines Laptops mit Fedora Core 4. Ich benutze KDE und wie jeder weiß wird dies mit dem Skript startkde gestartet. Seit heute morgen kann ich aber KDE nicht mehr starten, da darin eine Abfrage auf den Ordner /tmp mit Hilfe des Befehls "df" gemacht wird, um festzustellen ob noch genügend Festplattenplatz vorhanden ist. Dieser liefert immer das Ergebnis "0" was natürlich zum starten von KDE zu wenig ist. Die Fehlermeldung laut "Not enough free disc space on /tmp".
Die genaue Ausgabe ist:
Code: 
1K-Blöcke     Benutzt     Verfügbar    Ben%
7395804       7157820     0            100%
Ich bin am verzweifeln. Weiß jemand wo das Problem liegt?
Achja, als root kann ich ohne weiteres ein Datei in /tmp anlegen, also meiner Meinung nach keine Rechte-Problem.

Gruß odigo
 
das ist relativ klar die einstellung, dass 5/10/15 % des filesystems für root reserviert wird. hast du beim partitionieren eingestellt. einfach ein wenig aufräumen, dann hast du wieder freude mit dem linux
 
Das war ja auch mein erster Gedanke. Mittlerweile hab ca. 200 MB frei aber KDE will immer noch nicht. Gestern hatte ich bei weitem nicht mehr so viel frei. Ich habe sogar schon das ein oder andere Programm deinstalliert. Kann ich diese Root-Reservierung jetzt noch irgendwie kleiner machen? Ich weiß nicht was ich noch löschen bzw. auf die andere Platte verschieben soll.

gruß odigo

Edit: Ich habe zwar die Befürchtung daß das keiner mehr lesen wird, aber hier ist die aktuelle Ausgabe von df -h:
Code: 
Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/mapper/VolGroup00-LogVol00
                      7,1G  6,7G     0 100% /
/dev/hda5              99M   10M   84M  11% /boot
/dev/shm              244M     0  244M   0% /dev/shm
/dev/hda2              18G   16G  1,5G  92% /mnt/Acerdata
/dev/hda1              12G   10G  1,8G  86% /mnt/Windows
//192.168.1.2/I       4,9G  2,7G  2,3G  54% /mnt/I
Verfügbar 0!!! Wieso???
 
also mit

Code: 
tune2fs -m 0 /dev/...

kannst du das verändern, wird dir aber vielleicht keine grosse freude bringen, denn wenn das filesystem voll ist, dann kannst du anfangen im single-user-mode aufzuräumen :-)

evtl. mal

Code: 
sudo apt-get clean

machen und damit den apt-cache löschen, d.h. die temporär gespeicherten debs von installierten programmen löschen.

falls danach noch immer nichts geht kontrollier mal die rechte von /tmp. sollten 777 sein
 
Danke!
Das Platzproblem schließe ich mittlerweile mal aus. 400 MB sind selbst für KDE mehr als ausreichend.
Irgendwie hab ich die Befürchtung daß irgendwas mit dem Dateisystem meiner Platte nicht stimmt. Unter Knoppix sagt qtparted daß das FS unbekannt ist und fsck.ext3 /UNIONFS/dev/hda6 sagt irgendwas von "Bad magic number" und "Superblock ist unlesbar..." Bei google finde ich aber irgendwie keine einfache Lösung für das Problem. Kennt irgendwer eine Lösung? e2fsck -b 8193 ... bringts auch nicht. ;(
Auch wenns übers LAN Ewigkeiten dauern würde. Weiß jemand wie ich eine Datenrettung mit dd oder dd_rescue machen kann und alles danach 1:1 zurückschieben kann? Funktioniert das überhaupt mit einem kaputten Dateisystem?

gruß, der verzweifelte odigo :(
 
wie kommst du von einem kde-fehler auf ein fs-fehler?? kannst du linux noch starten?? dann müsste er doch auch einen superblock finden...

wie siehts denn mit dem smart-status der platte aus?

e2fsck -b 8193 wird dir ziemlich sicher nichts bringen, da ich nicht glaube, dass du eine blocksize von 1024 hast. andere werte wären: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553, 1024001, 1990657, 2809857, 5120001, 5971969

für eine blocksize von 4096 wären plausible werte: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

einfach nachzuprüfen mit

Code: 
sudo mkfs.ext3 -n -b xxx /dev/...

kaputtes dateisystem nutzt dir dd wenig... dd ist für kaputte hardware gut :-) aber das eine kann ja vom andern kommen ;-)

also mal smartmontools holen (knoppix dürft sie nativ haben) und platte checken.
 
Das mit dem FS-Fehler war nur eine Theorie. Daß KDE nicht startet ist ja nur das Symptom von der meiner Meinung nach falschen Ausgabe von df. Ich kann mich nur nach als root mit failsafe einloggen, alles andere geht nicht. Also ganz kaputt ist das FS wohl nicht.
Ich hab jetzt mal versucht mit smartctl -t long /dev/hda meine Festplatte zu überprüfen, was allerdings kläglich gescheitert ist. Daraufhin hab ich mal badblocks drüberlaufen lassen, was mir schon einige Fehler anzeigt. Wie ich das jetzt allerdings behebe weiß ich nicht.
Ich neige jetzt langsam aber sicher dazu das startkde-skript zu ändern und dies Abfrage mit df einfach auszukommentieren. Ich glaube schlimmer kanns eh nicht mehr werden :D
Für weitere Vorschläge bin ich aber nach wie vor offen.

gruß odigo

PS: ich lade mir nebenbei schon mal FC5 runter und die Preise für eine neue Festplatte hab ich mir auch schon angeschaut :D
 
momentmoment, nichts überstürzen hier...

wiso ist smartctl kläglich gescheitert?

und wiso stellst du nicht die prozenthürde hinunter statt ein kde-startskript zu manipulieren???

welche rechte hat der /tmp ordner?
 
smartctl führt den Test einfach nicht aus. Die Ausgabe vom smartctl -l selftest /dev/hda ist:
Code: 
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       70%      7250         19881657
# 2  Extended offline    Completed: read failure       70%      7250         19881657
# 3  Extended offline    Aborted by host               90%      7249         -

und wiso stellst du nicht die prozenthürde hinunter statt ein kde-startskript zu manipulieren???
Zum Vergrößern anklicken....
Sorry, den Satz kapier ich nicht.

Hier sind mal meine Anpassungen im startkde-script:

###############################
#!/bin/sh
#
# DEFAULT KDE STARTUP SCRIPT ( KDE-3.4.3 )
# Modified for Red Hat Linux
#

unset BLOCK_SIZE # breaks parsing of df output
shopt -u -o noclobber # allow overwriting of files with '>'

# set up user environment if not present
# check for space on /tmp and "$HOME" and for write access
# error exit, if not
#space_tmp=`df /tmp | xargs | cut -d" " -f11`
space_tmp=50
#homedir_mount=`df "$HOME" | xargs | cut -d" " -f8`
homedir_mount=50

if [ "$homedir_mount" = "AFS" -a -x "`which fs 2>/dev/null`" ] ; then
# check for AFS
#space_home=`fs df "$HOME" | xargs | cut -d" " -f10`
space_home=50
else
# check regular mounts
#space_home=`df "$HOME" | xargs | cut -d" " -f11`
space_home=50
fi

if [ $space_tmp -lt 50 ]; then
echo $"Not enough free disk space on /tmp"
exit 1
fi

if [ $space_home -lt 25 ]; then
echo $"Not enough free disk space on "$HOME""
exit 1
.
.
.
###############################

Durch diese Anpassung schaffe ich es als root ein KDE-Sitzung zu starten. Wenn ich allerdings als root eine Failsafe-Sitzung starte, mit su <benutzername> zu meinem Standarduser wechsle und dann startkde ausführe bekomme ich die Fehlermeldung daß ich keine Schreibrecht auf /tmp habe. Ich weiß nicht ob das normal ist :rolleyes:

Der Ordner /tmp hat die Rechte:
Code: 
drwxrwxrwt   35 root root 12288 16. Okt 12:26 tmp

Ich glaube ich weiß mittlerweile wenigstens die Ursache des Problems. Ich habe schlicht und ergreifend die Festplatte zum "überlaufen" gebracht. Das blöde was dazu kommt ist daß ich das erst gemerkt habe als ich gerade das KDE-Startmenü ändern wollte. Mir wurde dann ein Fehler gemeldet daß in Datei xy (mist, ich hab den Namen vergessen) nicht geschrieben werden kann. Deshalb ist eine weitere Vermutung von mir daß ich mir eben diese Startmenüdatei zerschoßen habe.


Edit:
Die Datei hieß applications-kmenuedit.menu. Momentan ist die Datei leer. Ich habe aber in einer Sicherungskopie geschaut und das sollte wohl nicht so sein. Ich ersetze die mal :D

Edit2:
hm, hab die Datei mal ersetzt. Das komische war daß ich daß nur als root machen konnte. Als ich es mit meinem User probiert habe, bekam ich eine Fehlermeldung daß zu wenig Speicherplatz zur Verfügung steht X( Also doch wieder das alte df-Problem.
Achja, gebracht hats nichts
 
also mal vorweg /tmp hat bei mir die gleichen rechte.

die ausgabe von smartctl würde ich jetzt nicht als nichtausführen bezeichnen, sondern einfach als fehlermeldung, d.h., dass der long-self-test nicht durchgeführt werden kann, weil ein fehler auf der disk ist. hatte ich neulich mal. habe einfach die disk komplett gespiegelt, low-level-format und dann das image zurückgespielt.

hast du schon mit tune2fs gespielt? vergiss das skripte manipulieren, der dirty hack bringt nur augenscheinlich was.
 
Ich glaube das Spiegeln bringt in meinem Fall nicht viel. Ich glaube daß durch den "Festplattenüberlauf" auch irgendwelche Systemdateien in Mitleidenschafft gezogen worden sind, nicht nur das Filesystem. Aber das will ich erst glauben wenn mir df wieder das richtige anzeigt, falls ich das überhaupt jemals schaffen sollte.

Was meinst mit "gespielt"? Aus der man-page werd ich nicht sonderlich schlau.

Ich hab mal
tune2fs -l /dev/mapper/VolGroup00-LogVol00
ausgführt und das kam dabei raus:

Code: 
tune2fs 1.37 (21-Mar-2005)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          75ed5941-431f-442e-94e5-b89bcabb54fc
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1908768
Block count:              1908736
Reserved block count:     95436
Free blocks:              92481
Free inodes:              1655012
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      465
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32352
Inode blocks per group:   1011
Filesystem created:       Wed Aug 24 01:36:44 2005
Last mount time:          Mon Oct 16 11:15:59 2006
Last write time:          Mon Oct 16 11:15:59 2006
Mount count:              2
Maximum mount count:      -1
Last checked:             Sun Oct 15 17:41:22 2006
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:		  128
Journal inode:            8
First orphan inode:       1197292
Default directory hash:   tea
Directory Hash Seed:      b272f70e-296c-42bb-9a57-73989633fe20
Journal backup:           inode blocks

Was mir das allerdings sagen soll, keine Ahnung ?(

Achja, zwischendurch hab ich mal das coreutils-paket geupdated (darin ist df enthalten), hat aber auch nichts gebracht.
 
Original von ElLute
also mit

Code: 
tune2fs -m 0 /dev/...

kannst du das verändern, wird dir aber vielleicht keine grosse freude bringen, denn wenn das filesystem voll ist, dann kannst du anfangen im single-user-mode aufzuräumen :-)
Zum Vergrößern anklicken....

dem smartctl ist das filesystem herzlich egal, das meldet wennschon physikalische fehler :-)
 
boah ElLute, ich küss dir die Füsse!!!!!

Code: 
tune2fs -m 0 /dev/mapper/VolGroup00-LogVol00
Das wars!!!!!!!!! (zumindest schauts danach aus)
KDE läuft auch wieder :D

df -h:
Code: 
Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/mapper/VolGroup00-LogVol00
                      7,1G  6,8G  357M  96% /
/dev/hda5              99M   10M   84M  11% /boot
/dev/shm              244M     0  244M   0% /dev/shm
/dev/hda2              18G   16G  1,5G  92% /mnt/Acerdata
/dev/hda1              12G   10G  1,8G  86% /mnt/Windows

So schaut das doch gleich wieder viel besser aus :D
Vielen vielen Dank!!!!!

Gruß odigo
 
du hast schon bemerkt, wo ich das schon geschrieben habe?!?

zur ausgabe von smartctl: es ist irgendwo ein physikalischer fehler auf der platte. d.h. wenns gut geht, kackt dir einfach eine datei ab, die du nicht mehr lesen kannst, wenns schlecht geht, verabschiedet sich die platte bald komplett. in produktivumgebungen würde so eine platte wohl nur mehr gespiegelt und in die tonne getreten...

ich würde dem problem auf alle fälle mal auf den grund gehen und ausserdem schauen ein wenig speicher freizuräumen, fast volle ext3-partitionen werden mit der zeit extrem langsam, weil die "defragmentierung" nicht mehr funktioniert (habe ich mir sagen lassen)
 
du hast schon bemerkt, wo ich das schon geschrieben habe?!?
Zum Vergrößern anklicken....

hm ja :( aber die Sache mit dem single-user-mode hat mich etwas abgeschreckt, obwohl ich eigentlich gar nicht weiß was das ist :D

zur ausgabe von smartctl: es ist irgendwo ein physikalischer fehler auf der platte. d.h. wenns gut geht, kackt dir einfach eine datei ab, die du nicht mehr lesen kannst, wenns schlecht geht, verabschiedet sich die platte bald komplett. in produktivumgebungen würde so eine platte wohl nur mehr gespiegelt und in die tonne getreten...
Zum Vergrößern anklicken....

Ich weiß, über kurz oder lang werd ich mir eh eine neue Platte zulegen. Sollte sie ganz abschmieren dann werd ich es schon überleben. Ich muss halt jetzt des öfteren mal die wichtigsten Sachen wegsichern.

ich würde dem problem auf alle fälle mal auf den grund gehen und ausserdem schauen ein wenig speicher freizuräumen, fast volle ext3-partitionen werden mit der zeit extrem langsam, weil die "defragmentierung" nicht mehr funktioniert (habe ich mir sagen lassen)
Zum Vergrößern anklicken....

ja, aber die 350 MB sollten erstmal reichen. Wenn ich mal Mut gefasst habe, werd ich mich mal daran machen von der Windowspartition was abzuzwicken (nachdem ich da aufgeräumt habe) und mit qtparted an die Linuxpartition anhängen. Windows ist eh nur für den Fall der Fälle da.

Also nochmal Danke für deine Geduld. Aber wenigstens hab ich durch den ganzen Mist wieder einiges dazugelernt.

Gruß odigo
 
was der single-user-mode ist, wirst du lernen, wenn du die platte jetzt vollmachst :-)

und zwar in grub beim starten ist ein punkt recovery mode. dort hast du nur eine root-konsole mit eher wenigen diensten (weiss ich nicht genau was alles) wo du auch noch reinkommst, wenn eine platte wirklich vollgelaufen ist oder sonst irgendwelche probleme aufgetreten sind, die linux nicht mehr wirklich starten lassen ;-)

des öfteren wegsichern heisst hoffentlich täglich?! in diesem zustand würde ich der platte nicht mehr unbedingt vertrauen. badblocks ist sicher kein schlechter weg, was ich evtl. empfehlen würde ist ein tool des herstellers, maxtor hat bsplsweise powermax, ibm den drivefitnesstest, andere haben sicher auch was... da kannst du evtl. auch eine sector-repair vornehmen (funktionierte bei der festplatte meines nachbars vor ein paar wochen ohne dateiausfälle), wenngleich ich das nicht ohne backup riskieren würde, oder gleich ein low-level-format...

hoffe ich habe nicht zu viel panik verbreitet, aber mit festplatten habe ich schon viel zu viel scheisse erlebt :-)
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben