Root-Partition voll, was kann ich tun

Herz-von-Hessen · 24 März 2013

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

Sauerland · 24 März 2013

Wo liegen denn meine unnötigen Speicherfresser?

/dev/sdb5 ext4 14G 13G 0 100% /

Da würde ich mal ansetzen, überflüssige kernel löschen usw.

zerum · 24 März 2013

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 · 24 März 2013

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

Herz-von-Hessen · 24 März 2013

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 · 24 März 2013

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 · 24 März 2013

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 · 24 März 2013

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% /

Herz-von-Hessen · 24 März 2013

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 · 24 März 2013

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 · 24 März 2013

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.

Spielwurm · 24 März 2013

Code:

rpm -qa | wc -l
2102

Herz-von-Hessen · 27 März 2013

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 · 23 Juni 2013

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!

Root-Partition voll, was kann ich tun

Herz-von-Hessen

Sauerland

zerum

gehrke

Administrator

Herz-von-Hessen

spoensche

Spielwurm

gehrke

Administrator

Herz-von-Hessen

gehrke

Administrator

konqui

Spielwurm

Herz-von-Hessen

edgarkls