Beiträge von rebell21

  • Plattenplatz root Laufwerk

    btrfs filesystem df /


    Code
    linux-g7ok:~ # btrfs filesystem df /
Data, single: total=50.01GiB, used=43.37GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=5.00GiB, used=2.76GiB
GlobalReserve, single: total=175.17MiB, used=0.00B



    snapper list



    snapper list-configs



    Code
    linux-g7ok:~ # snapper list-configs
Config | Subvolume
-------+----------
root   | /

  • Plattenplatz root Laufwerk

    zypper lr -d



    Ich habe nur eine virtuelle Maschine. Deren Dateien sind aber bei mir im home-Verzeichnis gespeichert und nicht in root. Daher ist mein Homeverzeichnis auch so groß.
    Also die vm liegt unter ~peter/vmware


    Das Löschen des Snapshots 369 geht auch nicht in "yast-snapper" es kommt die gleiche Fehlermeldung.

  • NVIDIA Probleme nach upgrade auf OpenSuse Leap 15

    Das Problem ist gelöst.


    Folgende Lösung hat geholfen


    1. nvidia nutzt die xorg.conf im Verzeichnis /etc/X11
    2. Im Original enthält diese folgende Zeilen


    Code
    Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection


    3. Ich habe die beiden Zeilen "HorizSync 28.0 - 33.0" und "VertRefresh 43.0 - 72.0" geändert in "HorizSync "30.0 - 83.0" und "VertRefresh 56.0 - 75.0"


    Die neue xorg.conf

    Code
    Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection


    Neustart und dann waren alle früher genutzten Auflösungen wieder vorhanden.




    Das Problem war auch nicht der KVM Switch. Auch der direkt angeschlossene Monitor zeihgt mit der originalen xorg.conf nur sehr geringe Auflösungen.


    Und xrandr --addmode geht in der Tat nicht bei nvidia. Wird auch ganz oft im Internet bestätigt

  • Plattenplatz root Laufwerk

    snapper delete --sync 369 geht leider nicht


    Code
    linux-g7ok:~ # snapper delete --sync 369
Deleting snapshot failed.

    Wieso soll dieser snapshot ein Problem sein ? Er ist vom Dezember. Und das Plattenplatzproblem habe ich seit Mittwoch


  • Plattenplatz root Laufwerk

    snapper -c root get-config | grep QGROUP



    Code
    linux-g7ok:~ # snapper -c root get-config | grep QGROUP
QGROUP                 | 1/0

    Der enorme Anstieg des Plattenplatzverbrauches ist aber erst mit dem upgrade auf Leap 15.0 gekommen. Vorher war das mit 38 % in Ordnung


    Ich habe nur eine virtuelle Maschine und deren Plattenplatz ist im Homeverzeichnis und damit auf einer anderen Platte (/dev/sdi4)

  • Plattenplatz root Laufwerk

    Das Kommando


    du -ckhs * | sort -rn | head -11


    hat folgendes Ergebnis erbracht.


    Dort werden für die größten 11 "Verbraucher" ca. 20 GByte angegeben. Wo sind die restlichen 40 GByte (60 GB sind belegt - 20 GByte in /). Außer dem root FS ist nichts auf der Platte.


    Die 28G für Home sind auf einer anderen Platte untergebracht (/dev/sdi4).

  • Plattenplatz root Laufwerk

    btrfs subvolume list /


  • Plattenplatz root Laufwerk

    btrfs filesystem show

    Code
    linux-g7ok:~ # btrfs filesystem show
Label: none  uuid: 58a5a1dd-8ed5-4e7e-a675-d1daeaa8dfcc
        Total devices 1 FS bytes used 46.08GiB
        devid    1 size 80.00GiB used 60.07GiB path /dev/sdi3

    verstehen tue ich es nicht


    Vor dem upgrade mit zypper dup war ca. 38 % belegt (31 Gbyte). Nun sollen 60 GByte belegt sein. Auf der Platte /dev/sdi3 ist nur das root FS

    btrfs qgroup show /



    Code
    linux-g7ok:~ # btrfs qgroup show /
ERROR: can't list qgroups: quotas not enabled

  • Plattenplatz root Laufwerk

    das habe ich gemacht, hat aber nur 1 % gebracht, nun von 73% auf 72 % belegt