Moin,
ich habe vie "DEF" einen Timer angepasst, und via "save config" gespeichert.
Jetzt sehe ich gerade, das meine komplette fhem.cfg leer ist (0kb).Meine letzte Sicherung ist fehlgeschlagen, und das letzte verfügbare Backup ist somit 2 Wochen alt. Da ich aber zwischenzeitlich neue Devices hinzugefügt habe, möchte ich das ungern alles händisch wiederherstellen.
FHEM läuft noch, und ein erneutes "save config" bringt leider nichts.
Ist die Konfig nicht auch in der fHEM.save gespeichert ? Wenn ja, wo finde ich diese ? Bzw. gibt es Alternativen zur wiederherstellung ?
LG
Klingt danach, als ob kein Speicher auf der HD/SSD/SD frei wäre.
Kontrollier das mal mit
stefan@cubie2:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.0G 2.8G 4.0G 41% /
Wenns wirklich so ist, irgendwas löschen und nochmal save ausführen.
Hi,
danke für Deine Antwort. Sowas vermute ich auch.
Selbst wenn ich FHEM mit neuer Konfig starte, führt ein speichern der Konfig aus FHEM heraus dazu, das die Datei nachher 0 Inhalt hat.
Hier das auslesen der SD-Karte:
Dateisystem Gr▒▒e Benutzt Verf. Verw% Eingeh▒ngt auf
rootfs 7,1G 7,0G 0 100% /
/dev/root 7,1G 7,0G 0 100% /
devtmpfs 215M 0 215M 0% /dev
tmpfs 44M 700K 44M 2% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 88M 0 88M 0% /run/shm
/dev/mmcblk0p1 56M 9,7M 47M 18% /boot
tmpfs 100M 0 100M 0% /tmp
Zitat/dev/root 7,1G 7,0G 0 100% /
Du weißt hoffentlich, was die 100% unter "Verwendet" bedeuten?
Ja, klar. :-[
Nur wo finde ich jetzt den versteckten Speicherfresser ? Ich vermute ein Backup ist nicht auf meinem NAS gelandet, sondern wurde versucht auf die SD-Karte zu schreiben...
Da kannst Du mit dem Befehl 'du' mal auf die Suche gehen...
Da finde ich leider keine einzelne Datei die so gross ist (Backupfile)
du mit der option -a (all) eingeben in /opt
Siehe:
ZitatSYNOPSIS
du [OPTION]... [FILE]...
EXAMPLES
DESCRIPTION
Summarize disk usage of each FILE, recursively for directories.
Mandatory arguments to long options are mandatory for short options too.
-a, --all
write counts for all files, not just directories
-B, --block-size=SIZE use SIZE-byte blocks
-b, --bytes
print size in bytes
-c, --total
produce a grand total
-D, --dereference-args
dereference FILEs that are symbolic links
-h, --human-readable
print sizes in human readable format (e.g., 1K 234M 2G)
-H, --si
likewise, but use powers of 1000 not 1024
-k
like --block-size=1K
-l, --count-links
count sizes many times if hard linked
-L, --dereference
dereference all symbolic links
-S, --separate-dirs
do not include size of subdirectories
-s, --summarize
display only a total for each argument
-x, --one-file-system
skip directories on different filesystems
-X FILE, --exclude-from=FILE
Exclude files that match any pattern in FILE.
--exclude=PATTERN Exclude files that match PATTERN.
--max-depth=N
print the total for a directory (or file, with --all) only if it is N or fewer levels below the command line argument; --max-depth=0 is the same as --summarize
--help
display this help and exit
--version
output version information and exit
VG
Frank
Na, damit hat sich wohl Deine Vermutung zerschlagen --> weitersuchen 8)
Nachdem Dein System ja proppevoll ist - sowas ist nie gut - würde ich als Sofortmaßnahme mal ein paar unwichtige Logs oder Temporärdateien löschen. FHEM-Logverzeichnis, oder unterhalb von /var ...
Dann kannst Du auch mal mit dem find-Befehl nach log und tmp-Dateien oder sonstigen Downloads etc. suchen (ich weiß ja nicht, was Du auf dem System so alles machst), und wenn Du da nix findest, was massiv ausser der Reihe ist, sollte man mal einen Gedanken an einen größeren Datenträger verschwenden.
Danke, hatte schon mit du -ah
hier aus /opt
80M ./FHEM
40M ./sonic-pi
39M ./vc
Was ich generell schon mache, ist das FHEM alle LOGS auf den angeschlossenen USB-Stick schreibt.
Aber irgendwo hängt der Wurm in der SD-Karte
Habe jetzt als User "root" mit find -size +5M
alle Unterverzeichnisse durchsucht und nichts aussergewöhnliches gefunden. Komisch.
cd /
du -h --max-depth=1
-> kaffee trinken.
Kleinvieh kann auch viel Mist machen :-X
find / -size +5M
durchsucht alle Verzeichnisse auf der Karte beginnend vom Root-Verzeichnis, aber mit der Einschränkung nur Dateigrösse > 5M
Hat aber nichts gebracht.
Morgen bekomme ich einen 2. Raspi, dann wird neu aufgesetzt.... :-[
Gerade mal geschaut, selbst wenn ich via Putty eine neue fhem.cfg erstelle, wird sie kurzerhand ein paar Minuten später vn FHEM selbständig wieder gelöscht. Ist das normal ?
LG
Was machst Du denn da? :o
Auf einem System mit 100% voller Platte ist nichts normal oder vorhersehbar. Wenn Du ein autosave drin hast und fhem zu speichern versucht, kann das gut sein.
Deinen find-Befehl haben wir schon verstanden, aber nochmal: es kann auch sein, dass Du irgendwo haufenweise kleine Dateien hast. Nicht nur FHEM schreibt Logs...
Und ein neu aufgesetzter Raspi kann nach einem Weilchen das gleiche Problem wieder haben...
Ja, ich habe verstanden 8) , aber Autosave war ein guter Hinweis.
Ich denke auch das da viele Logs etc von Programmen geschrieben werden, die ich irgendwann testweise installiert und dann doch nicht mehr genutzt habe....
Wie gesagt, gleich kommt mein 2. Raspi, und dann wird neu aufgesetzt...
Mit
du -sh -BM /* |sort -nr
Kannst du dir die Größen der Verzeichnisse in / anzeigen lassen und wenn da ein besonders großes bei ist z.B. /opt dann mit
du -sh -BM /opt/* |sort -nr
weitersuchen, dann findest du schon die Monster
Edit: Hab noch Sortierung und Größenangabe ergänzt
@Strauch, danke !
Die Parameter beim Suchbefehl kannte ich noch nicht.
root@raspberrypi:~# du -sh /*
5,9M /bin
9,7M /boot
19M /boot.bak
0 /dev
6,6M /etc
36M /home
129M /lib
16K /lost+found
du: Zugriff auf ▒/media/nas▒ nicht m▒glich: Der Rechner ist nicht aktiv
142M /media
4,0K /mnt
628M /opt
du: Zugriff auf ▒/proc/6106/task/6106/fd/4▒ nicht m▒glich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf ▒/proc/6106/task/6106/fdinfo/4▒ nicht m▒glich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf ▒/proc/6106/fd/4▒ nicht m▒glich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf ▒/proc/6106/fdinfo/4▒ nicht m▒glich: Datei oder Verzeichnis nicht gefunden
0 /proc
92K /root
700K /run
6,7M /sbin
4,0K /selinux
4,0K /srv
0 /sys
0 /tmp
1,7G /usr
1,4G /var
root@raspberrypi:~#
In der Summe komme ich da gerade mal auf knapp über 4GB. Die SD-Karte ist aber ~8GB
Das stimmt, aber zu Lebensrettung könntest du mal in var schauen ob das apt archive groß ist
du -sh -BM /var/cache/apt/* |sort -nr
Das könntest du mit
sudo apt-get clean
löschen und erst mal wieder etwas Platz bekommen.
Mein Var Verzeichnis ist nur 222MB groß.
Edit Hinweis:
Mit
du -sh -BM /* |sort -nr
So wird alles in MB ausgegeben und nach Größe sortiert ist noch übersichtlicher
Habe ich gemacht, waren aber nur ca 60MB.
/var/swap ist bei mir 1,1G gross...
Ich hab an der Stelle kein Swap (nutze aber auch kein RaspPi). Aber die Größe ist eigtl. 512MB+RAM, was ca. 1GB gibt.
Bin leider auch Linuxanfänger, mehr fällt mir gerade nicht ein.
Kein Problem, dennoch danke. Wieder ein Stück weiter in der Linuxwelt
Für den Linux-Einsteiger: über df -h kannst Du Dir Deine Partitionen ansehen.
Ich würde vorschlagen, Du rufst mal raspi-config auf und machst darüber ein Expand Filesystem, und wirfst dann nochmal einen Blick auf den verfügbaren Platz...
Daran hatte ich auch schon gedacht, aber das ist doch m.W. nur für Partitionen > 2GB wichtig. Und da meine 8GB sauber erkannt werden, habe ich es wohl ganz am Anfang beim einrichten gemacht.
Wie auch immer, schadet ja nichts, habe ich nochmal gemacht, hat jedoch nichts gebracht
na, da bin ich jetzt mit meinem Linux-Halbwissen am Ende, aber wenn Dir da 4 GByte fehlen, müssen die ja irgendwo sein...