Beiträge von keineheulsuse

Zitat von wurzel99

na ja ... ich glaub du hast dir ncdu nicht richtig angeschaut ..
aber wenn dir dein 'du -hx -d 1' aussagekräftig genug ist .. es scheint dir aber nicht die Problemdateien zu liefern.

Es sollte dir schon wichtig sein, wer hier das Filesystem vollmüllt. Dabei helfen cronjobs kaum.
Ursachen bekämpfen - nicht die Symptome.

ncdu verstehe ich als du mit ncurses-Oberfläche. Damit dürfte die Suche nach Quellen des Speicherplatzmangels
in der Tat einfacher sein.
Wer müllt mir die Platte zu - das Dateisystem selbst mit Snapshots, und zypper in /var/tmp. Gut in /var/log
kann man auch noch auf ~ endende Dateien löschen.

ncdu ist nett, du -hx -d 1 / tut es allerdings auch. Die interessante Beobachtung: df -h zeigte gestern noch fast
vollständige Belegung, heute dagegen nur noch 53%, was halbwegs zu den du-Daten paßt, obwohl am
Dateisystem nichts mehr verändert wurde (bis auf /var/log u.ä. natürlich). Der Speicher wurde anscheinend
verzögert freigegeben, obwohl ich den Rechner nach dem Löschen rebootet hatte, um alle Prozesse, die
eventuell noch handles offenhaben, zu beenden.
Wahrscheinlich setzte ich jetzt cronjobs auf, die /var/log usw. bereinigen.

Zitat von Berichtigung

Bei den Snapshots aufrüumen.
(Da kann man ziemlich viel löschen; wenn es läuft, sogar alle)

btrfs lernen

Nachdem das Dateisystem schon eine Kostprobe seines Könnens geliefert hat,
brenne ich förmlich darauf.

Hallo,

mit großer Begeisterung mußte ich feststellen, daß einer meiner Rechner hängt, da das auf /dev/sda2 liegende
Rootverzeichnis die Partition fast völlig ausfüllt: Löschen in /tmp und /var/tmp brachte kaum Erfolg, auch in
/var/log alle auf ~ enden Dateien löschen brachte kaum etwas. snapper delete 1 funktioniert nicht, alle
anderen Snapshots sind gelöscht.
df -h liefert

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs         32G    4,0K   32G    1% /dev
tmpfs            32G    196K   32G    1% /dev/shm
tmpfs            32G    2,6M   32G    1% /run
tmpfs            32G       0   32G    0% /sys/fs/cgroup
/dev/sda2        41G     37G  2,0G   96% /
/dev/sda2        41G     37G  2,0G   96% /.snapshots
/dev/sda2        41G     37G  2,0G   96% /tmp
/dev/sda2        41G     37G  2,0G   96% /var/tmp
/dev/sda2        41G     37G  2,0G   96% /var/spool
/dev/sda2        41G     37G  2,0G   96% /usr/local
/dev/sda2        41G     37G  2,0G   96% /srv
/dev/sda2        41G     37G  2,0G   96% /opt
/dev/sda2        41G     37G  2,0G   96% /boot/grub2/x86_64-efi
/dev/sda2        41G     37G  2,0G   96% /boot/grub2/i386-pc
/dev/sda2        41G     37G  2,0G   96% /var/opt
/dev/sda2        41G     37G  2,0G   96% /var/lib/pgsql
/dev/sda2        41G     37G  2,0G   96% /var/crash
/dev/sda2        41G     37G  2,0G   96% /var/lib/mysql
/dev/sda2        41G     37G  2,0G   96% /var/lib/named
/dev/sda2        41G     37G  2,0G   96% /var/lib/mailman
/dev/sda2        41G     37G  2,0G   96% /var/lib/libvirt/images
/dev/sda2        41G     37G  2,0G   96% /var/lib/mariadb
/dev/sda2        41G     37G  2,0G   96% /var/log
/dev/sda3       2,0T    136G  1,9T    7% /home

während du -hx -d 1 /

36M     /etc
58M     /boot
15G     /usr
1016M   /var
5,2M    /bin
518M    /lib
16M     /lib64
160K    /root
12M     /sbin
0       /mnt
0       /selinux
16G     /

liefert. btrfs filesystem df / meint

Data, single: total=32.69GiB, used=15.55GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=3.62GiB, used=938.36MiB
GlobalReserve, single: total=320.00MiB, used=0.00B

Ein fast baugleicher und mit fast gleicher Software bespielter Rechner, der allerdings längere Zeit nicht gelaufen ist, kommt nur auf eine 48%ige Belegung von /dev/sda2.
Der Vollständigkeit halber noch snapper -list (Nach Löschaktion)

Typ    | # | Vor # | Datum                       | Benutzer | Bereinigen | Beschreibung          | Benutzerdaten
-------+---+-------+-----------------------------+----------+------------+-----------------------+--------------
single | 0 |       |                             | root     |            | current               |              
single | 1 |       | Fr 13 Nov 2015 20:49:52 CET | root     |            | first root filesystem |

Tja jetzt ist guter Rat teuer. Wie bekomme ich den wahrscheinlich vom Dateisystem verschwndeten Speicher wieder frei?

MfG

Interessanterweise stürzt der modem-manager-gui auf dem oben geschilderten Rechner ab, bevor auch nur ein GUI geöffnet wird.
Es mutet mich alles seltsam an.

Nachdem der LTE Speedstick V bei mir Probleme mit der Einwahl verursachte, dann aber stabil lief, ist jetzt nach
einigen Aktionen im Verbindungseditor (Verbindung löschen, Verbindung wieder einrichten) eine gänzlich neue
Situation entstanden:
Hinzufügen - mobiles Breitband Huawai E3372
Deutschland
T-Mobile (Telekom)
internet.t-mobile (als Tarif)
und ein paar next kommt die Fehlermeldung:

No plugin supported adding this connection.

Ich bin begeistert und warte voller Hoffnung auf Plasma 6.

Zitat von wurzel99

nimm einfach die 13.2 oder 13.1

Mit Leap und Internet-Usb-Sticks sind die Foren voll.

Unter 13.1 und 13.2 findest du an software in aktuell alles was du möchtest und es funzt. Leap brauch noch ein Weilchen ..

Ein schlechter Rat. Während der Stick unter Leap instabil läuft, läuft er unter 13.2 überhaupt nicht. Wird der von dem älteren Kernel
überhaupt unterstützt? Die Probleme mit Leap gehen wohl in erster Linie auf dieses Prä-Alpha-Plasma-5-Experiment zurück.

Zitat von Sauerland

Es kann weiter gehen.

Ja, es geht weiter. Ein Huawei E173, der unter einer SuSE 12.x out of the box lief, macht unter Leap42.1 die gleichen Probleme. Erinnerungen
an aktive ISDN-Karten werden wach ...

Zitat von Sauerland

Wieso das?

Da habe ich wohl beim Überfliegen von einigen Artikeln etwas falsch aufgeschnappt. Nun ja: Welcher Surfstick funktioniert denn
unter Leap42.1 ohne Kernelexperimente zusammen mit der Telekom-SIM? Einen Stick zu kaufen erscheint mir sinnvoller, als mich
mit solchen Problemen herumzuschlagen.

Trotz PIN-Eingabe im Verbindungseditor (diese PIN bleibt auch nach einem Reboot erhalten) fragt KDE bei jedem Einstecken
des Sticks nach der PIN und anschließend möchte ein Dialog noch das Root-Paßwort. Dafür aber ist bei der Telekomverbindung
nach dem Reboot Benutzername und Paßwort trotz Speicherns im Verbindungseditor verschwunden. Ein Bug im Kernel mag die Geschichte vielleicht
instabil machen, aber KDE scheint hier auch recht eigenwillig zu agieren.
Da mein älterer O2-Stick (auch ein Huawei, jedoch ohne LTE) genau die gleichen Probleme zeigt, sprich gar nicht läuft, liegt
der Verdacht hinsichtlich eine KDE-Beteiligung am Problem für mich nahe. Daher habe ich auch keine große Lust, mir einen
neuen Stick zu kaufen, um dann ggf. festzustellen, daß auch der nicht funktioniert.
Wo speichert eigentlich KDE die Informationen über Netzwerkverbindungen des Nutzers?

Ich dachte übrigens, in Leap42 flössen mehr Aktualisierungen ein, also auch hinsichtlich des Kernels.

MfG

P.S.: Das Verlieren von Benutzername und Paßwort tritt nicht ständig auf.