• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Root-Partition voll, was kann ich tun

Hallo

Ich habe ein Problem das zwar schon viele male hier beantwortet wurde, aber es passt nicht recht auf meine Situation, denn meine Root-Partition läuft voll und ich kann nahezu nichts mehr installieren.
Die meisten Threads beziehen sich auf /tmp und die Logdateien (logrotate), aber bei mir ist /tmp eine eigene Partition und ich finde in /var/log keine Auffälligkeiten, aber seht selbst:

Code:
herz-von-hessen:/home/herz # du -hxs /* --exclude=Daten --exclude=Lager --exclude=minthome --exclude=mintroot --exclude=media --exclude=mnt --exclude=home --exclude=tmp --exclude=windows /* 2>/dev/null
4,2M	/bin
55M	/boot
4,0K	/dev
23M	/etc
232M	/lib
20M	/lib64
16K	/lost+found
382M	/opt
0	/proc
15M	/root
4,2M	/run
7,0M	/sbin
4,0K	/selinux
1,4M	/srv
0	/sys
8,5G	/usr
2,0G	/var
Die Mountpoints habe ich mit --exclude herausgenommen.
Da tauchen gar keine GB sondern nur MB auf :???:

Hier eine Disk Free Ausgabe:
Code:
herz-von-hessen:/home/herz # df -hT
Dateisystem    Typ      Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs       devtmpfs  3,9G    4,0K  3,9G    1% /dev
tmpfs          tmpfs     3,9G    156K  3,9G    1% /dev/shm
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /run
/dev/sdb5      ext4       14G     13G     0  100% /
tmpfs          tmpfs     3,9G       0  3,9G    0% /sys/fs/cgroup
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /var/lock
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /var/run
/dev/sdb6      ext4       14G    6,7G  5,7G   55% /mintroot
/dev/sdb1      fuseblk    30G     25G  5,0G   84% /windows/C
/dev/sda2      ext4      9,9G    151M  9,2G    2% /tmp
/dev/sdc4      fuseblk   151G    134G   17G   89% /Daten
/dev/sda3      ext4      216G     29G  177G   14% /Lager
/dev/sdc3      ext4      197G    174G   23G   89% /home
/dev/sdc1      ext4       22G     19G  2,5G   89% /minthome

Und so sind meine Laufwerke & Partitionen aufgeteilt:

Code:
herz-von-hessen:/home/herz #  lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 232,9G  0 disk 
├─sda1   8:1    0     4G  0 part [SWAP]
├─sda2   8:2    0    10G  0 part /tmp
└─sda3   8:3    0 218,9G  0 part /Lager
sdb      8:16   0  55,9G  0 disk 
├─sdb1   8:17   0  29,4G  0 part /windows/C
├─sdb2   8:18   0     1K  0 part 
├─sdb5   8:21   0  13,3G  0 part /
└─sdb6   8:22   0  13,3G  0 part /mintroot
sdc      8:32   0 372,6G  0 disk 
├─sdc1   8:33   0    22G  0 part /minthome
├─sdc3   8:35   0   200G  0 part /home
└─sdc4   8:36   0 150,6G  0 part /Daten
sr0     11:0    1  1024M  0 rom

Was kann/muss ich tun um wieder Platz zu bekommen?
Wo liegen denn meine unnötigen Speicherfresser?

Lieben Gruß aus Hessen
 

zerum

Member
Herz-von-Hessen schrieb:
8,5G /usr
2,0G /var[/code]
Die Mountpoints habe ich mit --exclude herausgenommen.
Da tauchen gar keine GB sondern nur MB auf :???:
Naja, das sind schon mal 10,5GB. :/
Code:
8,5G	/usr
2,0G	/var
 

gehrke

Administrator
Teammitglied
Bei meinem frisch installierten OpenSUSE 12.3 belegt /usr noch nicht mal die Hälfte:
Code:
j3:~ # du -h --max-depth=1 /usr
228K    /usr/src
238M    /usr/lib
16K     /usr/x86_64-suse-linux
80K     /usr/local
1.7G    /usr/lib64
330M    /usr/bin
51M     /usr/sbin
4.0K    /usr/games
124K    /usr/include
1.8G    /usr/share
16K     /usr/X11R6
4.1G    /usr
 
Hallo Sauerland,

Sauerland schrieb:
Da würde ich mal ansetzen, überflüssige kernel löschen usw.
Bei mir ist folgedner Kernel aktiv:
Code:
herz-von-hessen:/home/herz # uname -a
Linux openSUSE-Desk 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux
Und installiert sind diese:
Code:
herz-von-hessen:/home/herz # rpm -qa | grep kernel
kernel-desktop-devel-3.7.10-1.1.1.x86_64
kernel-desktop-3.7.10-1.1.1.x86_64
kernel-firmware-20130114git-1.2.1.noarch
kernel-source-3.7.10-1.1.1.noarch
texlive-l3kernel-2012.60.svn_3570svn26111-4.2.1.noarch
kernel-devel-3.7.10-1.1.1.noarch
nfs-kernel-server-1.2.7-2.1.1.x86_64
Die kernel-source-3.7.10-1.1.1.noarch werde ich ja wohl brauchen, ebenso kernel-desktop-3.7.10-1.1.1.x86_64
Bei den anderen bin ich gar nicht sicher woher die kommen und ob die von etwas gebraucht werden.

@zerum
zerum schrieb:
Naja, das sind schon mal 10,5GB. :/
Ja /usr ist wirklich voll, also mal einen Blick hineinwerfen:
Code:
du -hxs /usr/* 2>/dev/null|sort
1,1G    /usr/lib
16K     /usr/x86_64-suse-linux
197M    /usr/local
1,9M    /usr/X11R6
2,3G    /usr/lib64
3,5G    /usr/share
4,0K    /usr/games
47M     /usr/include
620M    /usr/bin
622M    /usr/src
62M     /usr/sbin
67M     /usr/NX
93M     /usr/java
Hierbei tut sich /usr/share besonders hervor:
Code:
11M     /usr/share/cracklib
11M     /usr/share/grub2
12M     /usr/share/hplip
12M     /usr/share/poppler
13M     /usr/share/nmap
13M     /usr/share/sounds
14M     /usr/share/doc-bundle
15M     /usr/share/apache2
15M     /usr/share/mibs
16M     /usr/share/supertux
16M     /usr/share/hugin
17M     /usr/share/help-bundle
22M     /usr/share/gnome
25M     /usr/share/vim
32M     /usr/share/locale-bundle
34M     /usr/share/mlt-5
35M     /usr/share/templates
36M     /usr/share/ghostscript
38M     /usr/share/libreoffice
38M     /usr/share/wine
46M     /usr/share/gtk-doc
50M     /usr/share/YaST2
61M     /usr/share/man
73M     /usr/share/virtualbox
79M     /usr/share/supertux2
96M     /usr/share/gimp
96M     /usr/share/wallpapers
118M    /usr/share/cups
179M    /usr/share/kde4
201M    /usr/share/supertuxkart
222M    /usr/share/fonts
231M    /usr/share/locale
296M    /usr/share/texmf
528M    /usr/share/icons
588M    /usr/share/doc
Was aber doch eigentlich nichts "Schlimmes" sein sollte oder?

@gehrke
gehrke schrieb:
Bei meinem frisch installierten OpenSUSE 12.3 belegt /usr noch nicht mal die Hälfte:
Dabei ist mein System ja auch erst so neu wie die Distributionsnummer besagt.

Lieben Gruß aus Hessen
 

spoensche

Moderator
Teammitglied
Unter /var werden die Logs am wenigsten Speicherplatz verbrauchen.
Unter /var befindet sich auch der Cache vom Zypper, sowie die RPM- Datenbank nebst Informationen der installierten Pakete und sie werden mit Sicherheit einen nicht gerade geringen Anteil an den belegten 2 GB haben.

Unter /usr sind die Kernel- Sourcen etc. diejenigen, die am meisten Speicherplatz belegen.
 

Spielwurm

Advanced Hacker
Der Verbrauch sieht von den Anteilen ziemlich normal aus. Wenn ich das allerdings mit meinem Arbeitsrechner vergleiche, auf dem meiner Empfindung nach ziemlich viel installiert ist, dann musst Du ja noch viel mehr installiert haben. Und bei /var komme ich nicht mal auf ein GByte. Da wird Dir wohl nicht übrig bleiben, als die Partition zu vergrößern auf die von mir immer empfohlene Größe von 20G .-)
 

gehrke

Administrator
Teammitglied
Im Detail gibt es Bereiche, die sehen bei mir fast genau so aus:
Code:
118M    /usr/share/cups
96M     /usr/share/gimp
93M     /usr/share/wallpapers/
Andere Bereiche sind deutlich größer bei Dir:
Code:
103M    /usr/share/fonts (222M)
316M    /usr/share/doc (588M)
253M    /usr/share/icons (528M)
Ich würde auch sagen, Du hast einfach 'ne Menge Zeug installiert...

BTW: Ich komme eigentlich seit Jahren locker mit einer Systempartition von 10G für openSUSE aus ('boot' und 'home' ausgelagert).

Code:
j2:~ # df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/system-os2   9.9G  5.5G  4.0G  59% /
 
Hallo

Spielwurm schrieb:
Wenn ich das allerdings mit meinem Arbeitsrechner vergleiche, auf dem meiner Empfindung nach ziemlich viel installiert ist, dann musst Du ja noch viel mehr installiert haben

gehrke schrieb:
Ich würde auch sagen, Du hast einfach 'ne Menge Zeug installiert...
Ich fürchte das Ihr beide Recht habt und es wirklich zuviel installierte Pakete sind:
Code:
rpm -qa | wc -l
3277
Wie sieht das bei euch aus?

Lieben Gruß aus Hessen
 

gehrke

Administrator
Teammitglied
Herz-von-Hessen schrieb:
Ich fürchte das Ihr beide Recht habt und es wirklich zuviel installierte Pakete sind:
Code:
rpm -qa | wc -l
3277
Wie sieht das bei euch aus?

Code:
j2:~ # rpm -qa | wc -l
1614
Vielleicht hat das in meinem Fall etwas damit zu tun, dass ich diese Box nur als Client nutze. Die üblichen Dienste laufen auf einem dedizierten Server.
 

konqui

Hacker
Ich tippe mal auf die -üblichen Verdächtigen-...
mehrere Kernel(Sourcen) -> anscheinend nicht
.../BUILD und .../BUILDROOT
*.devel und *.32bit(wenn du x64 installiert hast) RPM's.
 
Hallo

Ich habe mal "aufgeräumt":

  • den mysql Dämon nicht gestartet (lieferte sowieso ständig Fehlermeldungen weil er (noch) nicht konfiguriert war.
  • Kernel-Files deinstalliert → http://sprunge.us/LSXP
und jetzt sieht es so aus:

Code:
rpm -qa | grep kernel
kernel-desktop-3.7.10-1.1.1.x86_64
kernel-firmware-20130114git-1.2.1.noarch

Ich hatte zwar etwas Bedenken das danach (wegen Nvidia) meine grafische Oberfläche nicht mehr starten könnte, was sich glücklicherweise als unbegründet herausgestellt hat :)
Auch weiß ich nicht was die ganzen texlive Pakete sind. Ich werde das wohl erst merken wenn ich genau diese Funktion benötige.

Code:
rpm -qa | egrep 'nvidia|nouveau'
libdrm_nouveau2-32bit-2.4.42-1.1.1.x86_64
nvidia-texture-tools-2.0.6-21.1.1.x86_64
nvidia-settings-270.41.06-1.9.x86_64
xorg-x11-driver-video-nouveau-1.0.6-2.1.1.x86_64
libdrm_nouveau2-2.4.42-1.1.1.x86_64

Habe ich jetzt keine proprietären Nvidia Treiber installiert?
Dennoch habe ich aber wohl ein funktionierendes GLX:

Code:
glxinfo | grep "direct rendering"
direct rendering: Yes

Wie dem auch sein, mein Problem um das es hier ja vorrangig geht ist damit ja gelöst, der Platz ist nun wie folgt:

Code:
df -hT
Dateisystem    Typ      Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs       devtmpfs  3,9G    4,0K  3,9G    1% /dev
tmpfs          tmpfs     3,9G     92K  3,9G    1% /dev/shm
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /run
/dev/sdb5      ext4       14G    9,7G  2,8G   78% /
tmpfs          tmpfs     3,9G       0  3,9G    0% /sys/fs/cgroup
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /var/lock
tmpfs          tmpfs     3,9G    4,4M  3,9G    1% /var/run
/dev/sdb6      ext4       14G    5,2G  7,3G   42% /mintroot
/dev/sdb1      fuseblk    30G     26G  4,3G   86% /windows/C
/dev/sda2      ext4      9,9G    154M  9,2G    2% /tmp
/dev/sdc4      fuseblk   151G    134G   17G   89% /Daten
/dev/sda3      ext4      216G     29G  177G   14% /Lager
/dev/sdc1      ext4       22G     19G  2,3G   90% /minthome
/dev/sdc3      ext4      197G    175G   22G   90% /home

Bei meiner nächsten Installation werde ich dann wohl meine / -Partition größer anlegen.
Ich bedanke mich bei allen die mir hier geholfen haben.

Lieben Gruß aus Hessen
 

edgarkls

Hacker
Das war genau der Thread, den ich brauchte. Im Glauben, die Root-Partition sei mit 30 GB großzügig bemessen, hatte ich dem Speicherverbrauch auf der Partition keine weitere Beachtung geschenkt. Bis dann plötzlich ein
Code:
zypper dup
mit der Meldung abbrach, dass der verfügbare Speicherplatz nicht ausreiche. Nach einigem Suchen bin ich über diesen Thread gestolpert und habe zum ersten Mal von der standardmäßig aktivierten 'multiversions'-Option in der zypper.conf gehört. Danach dann alle Schritte wie hier schon vorgegeben. Die alten Kernels nun sind weg, und plötzlich ist wieder richtig Platz für Updates und Neuinstallationen in meiner Root-Partition. Daher auch von mir ein herzliches Dankeschön an alle, die hier so enorm hilfreich waren!
 
Oben