[kaosman]

Seit ein paar Tagen startet mein MLD5.1 auf einem RPI nicht mehr. Der Bootbalken bleibt recht am Anfang hängen. Wenn ich dann auf die Konsole 1 wechsele, sehe ich die Meldung, dass kein Speicher mehr frei ist.

Code: [Select]

sh: write error: No space left on deviceEin df -a -h zeigt mir, dass eine Partition auf der Speicherkarte wohl voll ist. Da ich keinen Netzwerkzugriff habe, gibt es im Anhang ein altmodisches Screenfoto. 
An dieser Stelle bräuchte ich etwas Hilfe, wie ich den Fehler beheben kann ohne MLD neu aufzusetzen.

[Walter]

Moin,
Die sdcard an einem PC mit entsprechenden Lesegerät mounten, Platz schaffen und die Ursache  für den Platzmangel beseitigen.
mfg

[baltic]

Hallo,

ich kenne die 5.1 nicht, daher ist das jetzt "Stochern im Nebel." Trotzdem versuche ich es mal:

Möglicherweise liegen inzw. sehr viele snapshots auf Deinem System. Da könntest Du beim Booten mal die Liste aufrufen und alle Altlasten beseitigen.
Im zweiten Schritt würde ich Dir dann die Modernisierung Deines Systems ans Herz legen. 

Gruß
baltic

[kaosman]

Ich brauche nicht immer die neuesten Funktionen und habe lieber ein personalisiertes System, das ich einfach nutzen kann. Daher laufen meine VDRs eigentlich immer bis die Hardware schlapp macht.  Außerdem finde ich die 5.1 nicht sooo alt, mein anderes System läuft mit der 5.0.

Unter Windows sehe ich auf der SD-Karte nur eine Partition und die hat noch Platz frei.
Wie komme ich denn beim Booten in die Snapshot-Verwaltung? Ich kenne nur die Möglichkeit über das WebIF, was ich aber mangels Netzwerkverbindung nicht erreichen kann.

[clausmuus]

Nach dem Booten kannst Du das Tool "snapshot_manager" aufrufen (wobei ich nicht sicher bin, ob das in dem Zustand Deines Systems klappt). Damit kannst Du schauen ob viele Snapshots herumliegen und alte löschen. Wenn das Die Ursache Deines Problems ist, dürfte es damit behoben sein. Bewahre aber einen Snapshot aus der Zeit wo das System noch funktioniert hat auf, denn es kommt vor, dass bei Speichermangel die Datei /etc/rc.config beschädigt wird, und die müsste dann durch einspielen eines älteren Snapshots regeneriert werden.

Falls Du auch Aufnahmen auf der SD Karte speicherst, kann natürlich auch dies die Ursache des Speichermangels sein, oder wenn Kodi installiert ist, müsst das auch gerne die Speicherkarte voll. Es gibt noch ein paar andere Tools (wie z.B. den epg-daemon) die viele Daten sammeln und irgendwann den freien Platz voll aufgebraucht haben. Sollte es also nicht an den Snapshots liegen, müsste hier noch mal geschaut werden.

Bei der MLD-5.4 haben wir an einigen dieser Problemstellen gearbeitet, um ein volllaufen des Systemlaufwerkes zu verhindern.

[kaosman]

@clausmuus Besten Dank. Ich konnte 3 alte Snapshots aus 2017 löschen und nun startet er wieder.

Code: [Select]

MLD2> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2            1.7G      1.5G     97.0M  94% /
tmp                     366.3M      1.5M    364.9M   0% /tmp
run                     366.3M    476.0K    365.9M   0% /run
dev                     360.4M         0    360.4M   0% /dev
log                     366.3M     68.0K    366.3M   0% /var/log
/dev/mmcblk0p2            1.7G      1.5G     97.0M  94% /var/cache
/dev/mmcblk0p1           95.8M     10.2M     85.6M  11% /boot
//192.168.73.123/usbdisk1/VDR
                        916.9G    677.0G    239.9G  74% /mnt/data

epg-deamon habe ich nicht drauf und Aufnahmen landen auf der NAS, die per Freigabe eingebunden ist. Da bleibt eigentlich nur Kodi als Übeltäter übrig.
Mir ist außerdem aufgefallen, dass die Partition auf der Speicherkarte nur 1,7 GB nutzt, es ist aber eine 16 GB SD-Karte. Kann ich diese Partition verlustfrei vergrößern?

[baltic]

Hallo,

den Hauptteil der Karte dürfte die als Datenpartition angelegte mmcblk0p3 einnehmen. Schau mal, was

fdisk -l

sagt.
Warum ist die eigentlich nicht zu sehen? Ist der Einhängepunkt in der fstab auskommentiert?

Vergrößern ist nicht trivial. Mit btrfs kann gparted wohl umgehen, mit xfs aber nicht. Evtl. die dritte Partition löschen, die zweite vergrößern und am Schluss die dritte wieder anlegen.

Gruß
baltic

[kaosman]

Bei mir sieht es im Moment wie folgt aus:

Code: [Select]

MLD2> fdisk -l
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
64 heads, 32 sectors/track, 15193 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1               2          97       98304   b Win95 FAT32
/dev/mmcblk0p2              98        1886     1831936  83 Linux
MLD2> cat /etc/fstab
proc        /proc           proc      defaults            0 0
sys         /sys            sysfs     defaults            0 0
run         /run            tmpfs     defaults            0 0
tmp         /tmp            tmpfs     defaults            0 0
dev         /dev            devtmpfs  defaults            0 0
devpts      /dev/pts        devpts    mode=0620,gid=5     0 0
/dev/dvd    /media/dvd      auto      ro,noauto           0 0
/dev/cdrom  /media/cdrom    auto      ro,noauto           0 0
UUID=81ace40c-b5a9-4a7e-9c40-fa8d7f9942fc  /  auto  defaults  0 1
UUID=81ace40c-b5a9-4a7e-9c40-fa8d7f9942fc  /var/cache  btrfs  subvol=@cache  0 0
#UUID=81ace40c-b5a9-4a7e-9c40-fa8d7f9942fc  /mnt/data  btrfs  subvol=@data  0 0
UUID=4854-CBF4   /boot        auto      defaults            0 2
//192.168.73.123/usbdisk1/VDR /mnt/data cifs user=

Wenn ich meinen Eintrag auskommentiere und den Originaleintrag wieder einkommentiere, sieht es bei mount so aus:

Code: [Select]

MLD2> mount
/dev/mmcblk0p2 on / type btrfs (rw,relatime,ssd,noacl,space_cache,subvolid=313,subvol=/@root____________________)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
run on /run type tmpfs (rw,relatime)
dev on /dev type devtmpfs (rw,relatime,size=369008k,nr_inodes=92252,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
log on /var/log type tmpfs (rw,relatime)
/dev/mmcblk0p2 on /var/cache type btrfs (rw,relatime,ssd,noacl,space_cache,subvolid=257,subvol=/@cache)
/dev/mmcblk0p2 on /mnt/data type btrfs (rw,relatime,ssd,noacl,space_cache,subvolid=258,subvol=/@data)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
Ich werde mir mal Gparted anschauen.

[clausmuus]

Liegen im Ordner /data auf dem Root Filesystem eventuell Dateien? Oder auf den @data Filesystem wenn Du den Original mount verwendest? Das kann durchaus sein, wenn z.B. Dein NAS Mount mal nicht erfolgreich war und eine Aufnahme gestartet ist.

[kaosman]

Hab's überprüft, da waren keine Daten. Und Gparted hat nur 2 Partitionen anezeigt und 13 GB ungenutzt. Nach eine btrfsck --repair konnte ich mit Gparted dann auch die Partition vergrößern:

Code: [Select]

MLD2> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2           14.7G      1.5G     13.1G  10% /
tmp                     366.3M    940.0K    365.4M   0% /tmp
run                     366.3M    364.0K    366.0M   0% /run
dev                     360.4M         0    360.4M   0% /dev
log                     366.3M     56.0K    366.3M   0% /var/log
/dev/mmcblk0p2           14.7G      1.5G     13.1G  10% /var/cache
/dev/mmcblk0p2           14.7G      1.5G     13.1G  10% /mnt/data
/dev/mmcblk0p1           95.8M     10.2M     85.6M  11% /boot
Besten Dank für die kompetente und schnelle Unterstützung.