Beiträge von S. King

    Hallo Alero,

    Yast - Installieren/Entfernen - Suchfeld kernel eingeben - kernel-default markieren - unten auf Versionen
    Wieviele Kernel stehen da?

    Im graphischen Yast - Software installieren oder löschen - Suchfeld kernel


    Und dann? Sorry, ich stehe gerade ganz auf dem Schlauch. Wo sollte ich jetzt kernel-default sehen können? Mit Yast im Terminal sah ich es auch nicht.


    Wenn ich nicht nach "kernel", sondern direkt nach "kernel-default" suche, so sehe ich die Module kernel-default, kernel-default-base und kernel-default-devel, die jeweils NICHT installiert sind (sie sind in Version 3.16.7-24.1 verfügbar).


    Viele Grüße,
    Simon

    Hallo!

    Bei Platzproblemen mal ein flottes


    ncdu -X /


    angeworfen. Dann kann man schön durch die Ordner wandern und sich ansehen wo das Holz gestapelt ist.
    Ich hab da mit Schrecken erkannt, dass - ohne dass ich es gemerkt hatte (klar - ich bin selbst schuld) - KVM eben mal eine fette VM auf sda2 abgelegt hatte.

    Sollte es nicht eher ncdu -x / (mit kleinem statt großem x) sein?


    Jedenfalls ist das in der Tat ein sehr nettes Tool. Nur gewinne ich immer mehr den Eindruck, dass ich mir umsonst Sorgen machte bzw. der abnehmende freie Speicherplatz tatsächlich von Installationen stammt.


    Der meiste Platz auf / wird in /usr verbraucht (6.1G), dort das meiste in /usr/share (2.3G) und /usr/lib64 (2.2G). /usr/share verteilt sich auf viele Verzeichnisse (besonders doc, fonts und texmf), /usr/lib64 ebenso (libreoffice, jvm, thunderbird und firefox).


    Naja, ich glaube, ich lasse es mal so wie es ist und beobachte die Entwicklung. Vielleicht hat noch jemand eine Idee, wie ich snapshot 318 loswerde (siehe mein Post von 12:46 Uhr)?


    Viele Grüße,
    Simon

    Hallo!


    Vielen Dank an alle für die vielen Hinweise!


    Code
    > journalctl --disk-usage
    Journals take up 4.0M on disk.


    Code
    # du -hs /var/log
    104M	/var/log


    Wenn ich mich recht erinnere, hatte ich irgendwann mal dafür gesorgt, dass sich die logs nicht akkumulieren, aber ich weiß nicht mehr wie ich das gemacht habe.


    Code
    # find / -size 2G


    hat nichts gefunden. Es gibt also offenbar keine einzelne Datei, die viel Platz frisst. Nebenbeobachtung: In mehreren Fällen hieß es "Datei oder Verzeichnis nicht gefunden", und einmal "Keine Berechtigung", obwohl ich den Befehl als Root gab.


    Und im Zusammenhang mit Snapshots:

    Code
    find: File system loop detected; ‘/.snapshots/318/snapshot’ is part of the same file system loop as ‘/’.


    Ich fragte mich schon lange, warum ich diesen speziellen Snapshot nicht löschen kann. Was heißt "is part of the same file system loop"? Gibt es vielleicht doch eine Möglichkeit, Snapshot 318 zu löschen, ohne den Rest meines Systems zu zerstören?


    ncdu schaue ich mir gerade an.


    VIele Grüße,
    Simon

    Hallo Alero,

    Gute Frage. Meine beiden Dateien /usr/lib64 und /usr/share haben zwischen 1,7 und 2,1 GB. So tief steck ich jetzt nicht in der Materie, das ich weiß wie man die über Tage überwachen kann. Aber bei der Größe, die du noch zur Verfügung hast muß doch eine Datei oder auch paar mehr eine immense Größe aufweisen.

    Das dachte ich auch. aber mit


    und


    fallen mir auch keine Dinge auf, die "lösch mich" rufen.


    Anders gefragt: Sollte ich mir bei noch 5Gb freiem Platz auf der Root-Partition überhaupt Sorgen machen, oder ist das alles im Rahmen?


    Viele Grüße,
    Simon

    Hallo Alero,

    Tja, so eine Nummer hatten wir schon mal vor längerer Zeit. Nur mit dem Unterschied, das der User sein System gar nicht mehr starten konnte,
    Da schaust halt mal, wer der Übeltäter ist und warum.

    Dieser User war vermutlich ich. Damals ließ sich die Maschine durch Aufräumen der Metadaten in der Tat wieder zum Laufen bringen --- aber das scheint es eben diesmal nicht zu sein.


    Ich habe diesen neuen Thread übrigens genau aus dem Grund gestartet, weil mir keine Möglichkeit mehr einfällt, wie man den "Übeltäter" suchen könnte. Ich sehe, dass es nicht viele Metadaten gibt und ich sehe, dass /usr/lib64 und /usr/share viele Daten enthält. Aber wie finde ich heraus, ob und was ich da löschen kann?


    Gruß,
    Simon

    Hallo Alero!

    Liegt es nicht am "Snapshooting" dann suche nach "btrfs metadaten". Spätestens dann wirst du fündig.

    Bei mir ist es

    Code
    # btrfs filesystem df /
    Data, single: total=13.00GiB, used=11.72GiB
    System, DUP: total=32.00MiB, used=16.00KiB
    Metadata, DUP: total=1.62GiB, used=1.14GiB
    GlobalReserve, single: total=288.00MiB, used=0.00B


    Das sieht für mich auf den ersten Blick nicht nach übermäßig vielen Metadaten aus. Zumindest sind es nicht mehr Metadaten als Daten (das hatte ich früher mal, bevor ich regelmäßig die Snapshots löschte und die Partition defragmentierte und balancierte...).


    Viele Grüße,
    Simon

    Hallo!


    Auf meinem hp-Laptop läuft openSUSE 13.2. Meine Root-Partition hat 20Gb, und in letzter Zeit wurde der freie Platz auf der Root-Partition immer geringer: Jetzt sind es nur noch rund 5Gb, und das macht mir allmählich Sorgen:


    Vor wenigen Wochen waren noch 6,3G frei.


    Ich kann mir nicht erklären, woran das liegt. Snapshots lösche ich regelmäßig:


    und ansonsten sehe ich


    und


    Der größte Teil des Platzes geht also anscheinend für /usr/share und /usr/lib64 drauf. Aber wie finde ich heraus, ob es dort verzichtbare Dinge gibt, die ich gefahrlos löschen kann? Bzw. welche anderen Ansatzpunkte gibt es, um wieder mehr Platz zu schaffen? btrfs scheint es (so mein Eindruck) diesmal nicht zu sein, /tmp läuft auch nicht voll, und auch sonst habe ich hier im Forum keinen Thread gefunden, der auf meine Situation zu passen schien.


    Viele Grüße,
    Simon