[gelöst]Sys_partition (immer wieder?) voll

gm2601 · 8 Jan. 2020

Hallo Gurus,

schönes und erfolgreiches Neues Jahr!

Meins stimmt mich gerade verdrießlich, denn ...

... gestern den Rechner runtergefahren wie sonst auch und heute wie gewohnt gestartet aber kein Grafik-Mode mehr.

Im "init 3" fährt die Kiste hoch, nach "init 5" bleibt sie hängen, da hilft weder "shift-alt-F2" noch sonstwas, außer Reset. Bei anderen Versuchen wie

Code:

# startkde,
# xterm,
#...

bekomme ich die Meldung

Code:

$DISPLAY not set or cannot connect to X server

Wo setze ich den Hebel an, um mein 42.2 (

ps: ) wieder verfügbar zu bekommen?
Momentan schreibe ich von 11.3 aus, mein 15er auf einer SSD lief aufgrund von "Graphik-Insuffizienz" nie richtig?

Für hilfreiche Tipps bin ich wie immer dankbar

Gräfin Klara · 8 Jan. 2020

Gib ein:

Code:

# find ~/.config -name *.lock
# find ~/.cache -name *.lock

?

gm2601 · 9 Jan. 2020

Hallo Gräfin,

bei beiden Kommandos kommt NICHTS, weder wenn ich das von '/' noch von '/root' ausführe. Da scheint also kein lock-file gegeben zu sein und ich kann mir nicht recht vorstellen, dass das nur wegen 'init 3' so sein könnte, denn weiter komme ich ja nicht.

gm2601 · 9 Jan. 2020

Mon Dieu!!

ps: Meine Kiste bootet wieder! :thumbs:

Ich hatte nicht gemerkt, dass das root-Verzeichnis total voll war --ich habe auch keine Erklärung warum.
Nachdem ich nun /tmp gelöscht habe und zwei ältere Tipps von hier anwendete:

Code:

journalctl --vacuum-size=150M
rm /lib/modules/alt-kram

habe ich wieder micktrge 134M frei, aber immer noch "99% / used".

Der Hinweis auf zu wenig Platz kam, als ich in meiner Verzweiflung versuchte per zypper meine drei gfx-driver erneut zu installieren.

Die Aufgabenstellung hat sich also gewandelt: WO kann ich im root-directory noch "putzen", ohne mir das System zu zerschießen?

marce · 9 Jan. 2020

Ich rate mal BTRFS-Snapshots.

Ohne "Fakten" an denen man das "Drama" erkennen kann wird es aber beim raten bleiben.

josef-wien · 9 Jan. 2020

Wie groß ist die Systempartition? Welches Dateisystem wird verwendet?

gm2601 · 10 Jan. 2020

marce schrieb:
Ich rate mal BTRFS-Snapshots.

Nein, aber ext4 wird auch irgendwelche hinterhältigen Platzdiebe haben.

josef-wien schrieb:
Wie groß ist die Systempartition? Welches Dateisystem wird verwendet?

ext4 und leider nur 10 GB, da ich auf dieser Platte mal mit MINT experimentierte und die Systempartition bei der Inst von 42.2 nicht ordentlich formatierte.
Heute ist die Partition wieder total voll, ich muss wieder auf 11.3 zurückgreifen. Warum, frage ich mich, nach einem shutdown und heutigem boot.:???:

manzek · 10 Jan. 2020

Hallo gm2601,

ich will dir ja nicht zu nahe treten, aber meinst du nicht auch, dass es besser wäre, den Rechner mal grundlegend mit einer aktuellen Version von OS neu aufzusetzen? Deine Systeme sind nun 8, respektive 2 Jahre aus der Systembetreuung raus, und die meisten Repos sind vermutlich auch schon längst vom Netz genommen worden.

Die angesprochenen 'Grafikprobleme' dürften vermutlich einfacher in den Griff zu bekommen sein, als dieses Gefrickele mit Softwareleichen aus dem letzten Jahrzehnt.

Nix für ungut!

gehrke · 10 Jan. 2020

Zeig doch mal deine Partitionierung. Wenn Du LVM verwendet hast, sollte sich das Platzproblem doch wohl gerade ziehen lassen.

Bitte den Output von (als 'root' und in Code-Blöcken bitte):

Code:

df -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
lvs
pvs
cat /etc/fstab

Und bitte den Betreff dieses Thread anpassen an das aktuelle Problem.
TNX

gm2601 · 10 Jan. 2020

manzek schrieb:
Hallo gm2601,

Die angesprochenen 'Grafikprobleme' dürften vermutlich einfacher in den Griff zu bekommen sein, als dieses Gefrickele mit Softwareleichen aus dem letzten Jahrzehnt.

Nix für ungut!

Du magst recht haben, "dieses Gefrickele" bei jedem Update, jeder neuen Version, manchmal auch wegen Patches scheue ich auch, aber 15.x packe ich nicht mehr auf die alte Kiste und vor "diesem "Gefrickele" einer neuen, bis die dann wieder "mein PC" ist, graut mit schon heute.
Die momentane Frage ist, was knallt mir die Sys-Partition zu? :???:

Nix für ungut!

gm2601 · 10 Jan. 2020

gehrke schrieb:
Zeig doch mal deine Partitionierung. Wenn Du LVM verwendet hast, sollte sich das Platzproblem doch wohl gerade ziehen lassen.

Bitte den Output von (als 'root' und in Code-Blöcken bitte):

Code:

df -h lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT lvs pvs cat /etc/fstab

Und bitte den Betreff dieses Thread anpassen an das aktuelle Problem.
TNX

Code:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G   41M  1.8G   3% /dev/shm
tmpfs           1.9G  2.3M  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb2       9.8G  8.8G  441M  96% /
/dev/sdb3       285G  179G  107G  63% /home
/dev/sdb4       162G  9.8G  151G   7% /EXTRA
tmpfs           370M     0  370M   0% /run/user/0
tmpfs           370M   16K  370M   1% /run/user/1000

Code:

# lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME     SIZE TYPE FSTYPE MOUNTPOINT
sda    465.8G disk        
├─sda1     2G part swap   
├─sda2    20G part ext4   
└─sda3 443.8G part ext4   
sdb    465.8G disk        
├─sdb1     2G part swap   [SWAP]
├─sdb2    10G part ext4   /
├─sdb3 289.4G part ext4   /home
└─sdb4 164.4G part ext4   /EXTRA
sdc    232.9G disk        
├─sdc1     8M part        
├─sdc2    40G part btrfs  
├─sdc3 189.3G part xfs    
└─sdc4   3.6G part swap   
sr0     1024M rom

lvs und pvs zeigen nichts, da weder logical noch pysical Volumes definiert sind.

Code:

# cat /etc/fstab
UUID=0c1f2440-b49e-439a-a447-a1a4a8a55780 swap                 swap       defaults              0 0
UUID=e7c4aa3b-a493-4dfa-9ab7-3014d6ec0ac7 /                    ext4       acl,user_xattr        1 1
UUID=1cd38112-5481-41a6-bacb-462df4de6163 /home                ext4       acl,user_xattr        1 2
UUID=96908f06-3590-4956-ba8f-3aef19c4d67f /EXTRA               ext4       acl,user_xattr        1 2

sdc ist eine SSD, die ich für 15.x verwenden wollte, aber da harmonieren gfx-Driver und HW nicht.

Was mich arg irritierte, meine Sys-Partition, gestern etwas geräumt, heute beim boot schon wieder voll :???:
Bin gespannt, was nun nach reboot passiert oder gegeben ist.

gm2601 · 10 Jan. 2020

Tja, vor rebbot waren 295 MB frei, jetzt ist die Sys-Partition wieder voll, ich schreibe von 11.3 aus.

Code:

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              20G  6.2G   13G  33% /
devtmpfs              1.9G  236K  1.9G   1% /dev
tmpfs                 1.9G  4.0K  1.9G   1% /dev/shm
/dev/sda3             437G  174G  241G  42% /home
/dev/sdb2             9.9G  9.4G     0 100% /SDB2
/dev/sdb3             285G  179G  107G  63% /SDB3

Von 11.3 aus ist das /dev/sdb2

Der Vedacht auf Schad-SW verstärkt sich.

gehrke · 10 Jan. 2020

Schade, leider wurde kein LVM für die Partitionierung verwendet. Sonst könntest Du hier mal eben 15G wegnehmen und dort hinzufügen und wärst wahrscheinlich ohne Reboot in einer Viertelstunde fertig. :-(

Eine Neupartitionierung 'old-school' ist deutlich umfangreicher und riskanter.

Vielleicht dann doch erst noch mal mit 'du' recherchieren, wo der Platz belegt wird und ob noch was löschbar ist?

gm2601 · 10 Jan. 2020

gehrke schrieb:
[...]
Vielleicht dann doch erst noch mal mit 'du' recherchieren, wo der Platz belegt wird und ob noch was löschbar ist?

Habe ich gemacht und siehe da:

Code:

/SDB2/var/lib/systemd/coredump # ll
total 762M
-rw-r----- 1 root root 448M Jan  9 13:17 .#core.firefox-bin.1000.8aab2868a6e44548b7e3e5bcfa37cc9a.2491.15785722590000005ab5cbbc18110a07
-rw-r----- 1 root root 2.1M Jan  9 13:17 .#core.firefox-bin.1000.8aab2868a6e44548b7e3e5bcfa37cc9a.2491.1578572259000000.xz65140a1c5c1e8a84
-rw-r----- 1 root root 311M Jan 10 15:14 .#core.firefox-bin.1000.a05beb57fe3e4b6f84ffb8fb16f3a779.2430.15786656710000008a7f900e0cfa4feb
-rw-r----- 1 root root 1.4M Jan 10 15:14 .#core.firefox-bin.1000.a05beb57fe3e4b6f84ffb8fb16f3a779.2430.1578665671000000.xz77e4fb9087911ef7

das passt zur gestrigen und heutigen Zeit des reboots.
Ich habe die letzten Tage ein Update_angebot von firefox abgelehnt, weil ich anderweitig beschäftigt war. Das kann es doch hoffentlich nicht (gewesen) sein.
Lösche jetzt die dumps, mach den ff-update und boote danach.

gehrke · 10 Jan. 2020

Das sind ja ordentliche Brocken. Ich gehe davon aus, dass Dein akutes Problem mit dem Löschen der Dumps erledigt ist.

Und ja, auch ich rate Dir, unabhängig davon mal ordentlich aufzuräumen und wieder ein System zu installieren, welches sich im Support befindet.

gm2601 · 10 Jan. 2020

gehrke schrieb:
Das sind ja ordentliche Brocken. Ich gehe davon aus, dass Dein akutes Problem mit dem Löschen der Dumps erledigt ist.

FF ist auf Version 72.0.1, aber das kann es doch nicht gewesen sein. :irre:

Noch (!!) schaut es gut aus, auch nach dreifachem boot via Symbol und per

Code:

shutdown -r 0

ist kein dump da und die Sys-partition steht auf 93% voll und damit 735MB frei.

Und ja, auch ich rate Dir, unabhängig davon mal ordentlich aufzuräumen und wieder ein System zu installieren, welches sich im Support befindet.

Ihr habt ja alle recht, aber kein 15.x mehr auf diese Kiste und mir graut auch nicht vor den Kosten eines neuen PCs, aber vor dem "Gefrickele" bis die Kiste wieder wie gewohnt erscheint.

gehrke · 10 Jan. 2020

Nachtrag: Wenn ich nur 10G für das root-Filesystem hätte, würde ich die Coredump-Funktionalität entweder deaktivieren oder andere Speicherbereiche konfigurieren. Sonst wird Dir das möglicherweise noch häufiger passieren.

https://www.freedesktop.org/software/systemd/man/systemd-coredump.html

gm2601 · 11 Jan. 2020

Ihr Profis sagt das so einfach...mir geht es so:
Die (URL-)Botschaft les ich wohl, allein mir fehlt der Glaube...

Nicht der, dass ich nicht glaube man kann das machen, aber der Glaube, ich könne das machen.
Mein Bauch meint, dass das in den Bereich "lass die Finger davon, das kann ins Auge gehen" gehört..
Yast bietet da keine Möglichkeit an, oder ich habe sie nicht gefunden?

Mir fehlt auch der Glaube, dass ich in /etc/systemd/coredump.conf den Eintrag "external" schlicht durch "/EXTRA ersetzen kann, denn da hätte ich 151G frei.

gehrke · 11 Jan. 2020

Lass die Finger von YaST und probier es einfach mit dem Editor deines geringsten Mißtrauens aus. Du kannst zuvor ein Backup machen und hast für den Notfall ein lauffähiges Zweitsystem auf der Büchse. Was soll denn dabei schief gehen?

BTW: Wenn Du da schon Zweifel hast, würde ich mir überlegen, ob Du diese Dumps überhaupt jemals brauchst. So trivial zu lesen und zu verstehen sind die nämlich nicht.

gm2601 · 11 Jan. 2020

gehrke schrieb:
BTW: Wenn Du da schon Zweifel hast, würde ich mir überlegen, ob Du diese Dumps überhaupt jemals brauchst. So trivial zu lesen und zu verstehen sind die nämlich nicht.

Ist es wirklich soooo banal? Passiert ist erwartungsgemäß beim reboot nichts.

Code:

[Coredump]
Storage=none
#Compress=yes
#ProcessSizeMax=2G
#ExternalSizeMax=2G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=

Selbstredend gibt es noch ein /etc/systemd/Orig_coredump.conf und ich hatte bestimmt nie die Absicht einen dump zu lesen, gar zu interpertieren --wie käme ich als User dazu.

[gelöst]Sys_partition (immer wieder?) voll

gm2601

Gräfin Klara

gm2601

gm2601

marce

josef-wien

gm2601

manzek

gehrke

Administrator

gm2601

gm2601

gm2601

gehrke

Administrator

gm2601

gehrke

Administrator

gm2601

gehrke

Administrator

gm2601

gehrke

Administrator

gm2601