Hallo,
ich habe die neueste Version von FHEM auf einem Raspberry Pi Modell B mit Raspbian laufen.
Leider setzt sich FHEM nach einem Neustart des Pis immer wieder auf einen alten Zustand zurück. Sämtliche Änderungen in der fhem.cfg sowie erstellte GPlot-Dateien gehen dabei verloren, obwohl ich diese vorher gespeichert habe und nochmals mit "Save config" bzw. "save" im Befehlsfeld durchgeführt habe.
FHEM wird dabei nicht auf den Ursprungs-Zustand zurückgesetzt, sondern auf einen Zustand zwischen der Neuinstallation und heute.
Weiß jemand, wo das Problem liegt oder hilft hier nur eine neue Installation?
Hi,
das Problem hatte ich auch mal. Es lag an den Rechten auf dem Pi. Die fhem.cfg war für den User nicht schreibberechtigt und konnte die Datei nicht aktualisieren.
erstmal mit ls -la /opt/fhem die vorhandenen Rechte auslesen, dann mit chown -R %user%:%group% /opt/fhem die Rechte setzen (-R für recursive = durchreichen)
cu markus
P.S. wenn du samba einsetzt, dann für den Share ein "force user" setzten, sonst gehören die Dateien nicht mehr dem User "fhem". Das kommt echt übel, wenn man ein Script hat um die Log-Dateien zu archivieren, welches eine neue Log-Datei anlegt und FHEM darauf nicht schreiben darf... Don't try, it is no fun
Nach den Rechten habe ich schon geschaut. Die müssten doch so in Ordnung sein oder?
Ich hatte auch bereits einmal die fhem.cfg über SSH geändert. Aber nach einem Neustart war sie wieder überschrieben.
Gibt es nach dem Speichern eventuell Fehlermeldungen im Log?
ich würde nicht alle pauschal Schreibrechte mit vergeben. Nur dem User fhem.
Hallo zusammen,
es gab keine Fehler im Log. Nachdem ich FHEM neu aufgesetzt habe und es noch immer nicht funktionierte, habe ich das Image 1:1 auf eine andere SD-Karte kopiert. Und siehe da, es läuft wieder wie gewohnt.
Die "alte" SD-Karte lief jetzt etwa zwei Monate und scheint nicht defekt zu sein. Welche SD-Karte funktioniert bei Euch über längere Zeit einwandfrei?
Hätte ich den Pi nicht neu gestartet, wäre das Problem noch gar nicht aufgetaucht.
hi,
eine defekte SD - klar, das ist eine Erklärung. Aber das hätte doch noch mehr Auswirkungen haben müssen auf dem RasPi *staun*
zu deiner Frage: ich bin großer "SANDISK" Fan. Hab mir die ersten SD's mit meiner Spiegelreflex geholt und bisher keine einzige defekte Karte *3x auf Holz klopf*. Am einfachsten über die Webseite von raspi.org -> FAQ -> SD-Karten. So hab ich mir 2 ausgesucht (32GB und 8GB - aktiv werkelt die 32GB).
http://forum.fhem.de/index.php/topic,18482.msg123040.html#msg123040
schau mal hier, gleiches problem und mein lösungsansatz unten -> HDD nehmen. das mit der sd wird immer wieder passieren. je mehr du spielst und auf ihr schreibst desto schneller. lesen wirst du sie aber weiterhin noch sehr lange könne. schreiben ist das problem und da würd ich zu einer usb-hdd greifen. ist was platz angeht günstiger
Oh je. Wenn die SD-Karten wirklich so anfällig sind, greife ich tatsächlich zu einer HDD/SSD.
@Chris: Ist der "Umzug" von SD zu externem Datenträger irgendwo beschrieben? Geht auch ein USB Speicherstick oder ist der ähnlich anfällig wie eine SD-Karte?
ob das wirklich der grund war ? :o
wie dem auch sei, ich habe am wochende aufgrund log größe auch auf eine ssd die per usb angeschlossen ist, umgestellt.
SSD/HDD anstöpseln.
root@fhem:~# cat /proc/partitions
major minor #blocks name
179 0 15110144 mmcblk0
179 1 57344 mmcblk0p1
179 2 15048704 mmcblk0p2
8 0 61545960 sda
8 1 61544448 sda1
da ist sda mit sda1 -> das ist deine platte/deren partition
diese sollte ext4 formatiert sein.
das kann man so machen : (achtung alle daten auf der platte werden gelöscht)
root@fhem:~# mkfs.ext4 /dev/sda1
wenn das geschehen ist, muss die platte gemountet werden
root@fhem:/media# mkdir /sda1 && mount /dev/sda1 /sda1
jetzt kopierst du den inhalt der sd karte auf die platte :
rsync --exclude "/sda1" --exclude="/boot" -av / /sda1
last but not least, mit einem editor deiner wahl oder perl die /boot/cmdline.txt
von
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
zu
dwc_otg.lpm_enable=0 console=tty1 forcefsck root=/dev/sda1 rootfstype=ext4 elevator=deadline rootwait
ändern.
z.b. so : perl -i -pe's/mmcblk0p2/sda1/g' /cmdline.txt
nun daumen drücken und
root@fhem:~# shutdown -r now
und nach dem (hoffentlich erfolgreichem) booten mit
root@fhem:~# df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 258G 1,9G 254G 1% /
/dev/root 258G 1,9G 254G 1% /
devtmpfs 235M 0 235M 0% /dev
tmpfs 49M 256K 49M 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 98M 4,0K 98M 1% /run/shm
/dev/mmcblk0p1 56M 19M 38M 33% /boot
über die erfolgreiche einbindung der platte freuen.
keine garantie ::)
hier mein weg:
falls hdd gemounted (du musst natürlich schauen wie bei dir die hdd heisst per "ls /dev" zum bsp sda ist die hdd, sda1 die 1 partition sdaX die x. partition )
sudo umount /dev/sda1platte sauber machen (alle daten gehen verloren)
sudo fdisk /dev/sda d drücken, solange wie partitionen vorhanden sind / bis keine partition mehr auf der hdd sind
dann eine patition erstellen
n drücken für neue partition
pdrücken für primäre patition
weiter mit den angebotenen default werten um die ganze hdd zu nutzen
q zum beendet von fdisk
hdd formatieren
sudo mkfs.ext4 /dev/sda1sd-karte root auf hdd dublizieren
sudo dd if=/dev/root of=/dev/sda1 bs=4M...das dauert je nach sd größe
wenn fertig
e2fsck -f /dev/sda1da die genutzte größe der hdd nun der der sd entsprich resize
resize2fs /dev/sda1hdd mounten
sudo mount /dev/sda1 /media/usbstickwenn fehler mit
mkdir -p /media/usbstick das verzeichnis erstellen, dann nochmal mounten
sudo nano /media/usbstick/etc/fstabsollte dann so abgeändert werden
Zitat
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
/dev/sda1 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that
mmcblk0p2 ist das alte root der sd-karte
cmdline anpassen:
backup
sudo cp /boot/cmdline.txt /boot/cmdline.originaleditieren
sudo nano /boot/cmdline.txtso siehts dann aus
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline rootwaitund reboot und er sollte nun die hdd nutzen
sudo rebootich habe dies mit einer sd-karte mit meinem bereits eingerichteten fhem / system gemacht und es gab keinerlei probleme. fhem startete sofort und ohne fehler.
dies geht auch mit einem stick. jedoch ist ein usb-stick in der regel auch ein flashspeicher und ist also wie eine sd zu sehen
@juppzupp: wie sieht es bei dir bezüglich geschwindigkeit aus mit der ssd am usb.
ssd ist sicher etwas übertrieben oder, ich mein usb 2.0 und ssd? usb 2.0 kann ca 35 MBs und ne ssd mit ca 500MBs selbst eine hdd wird da nicht warm, die lanweilen sich. dagegen spricht dann auch noch der preis / GB (hdd ca 0,05-0,10 € sdd ca. 0,60 €)
steck die lieber in den rechner/laptop.
Vielen Dank. Die root-Partition liegt nun auf einer externen Festplatte.
Unschön ist nur, dass nun Raspberry Pi + CULs + aktiver USB Hub zusammen 7,5 Watt brauchen. Vorher waren es 3 Watt ohne USB Hub und HDD.
nunja, das ist bei mir ehr nebensächlich da eh den ganzen tag ein svr2008 am laufen ist. da haben allein die platten mehr bedarf als der pi samt zubehör
SSD macht keinen Krach und braucht weniger Strom.
Zitat von: juppzupp am 07 Januar 2014, 22:08:28
SSD macht keinen Krach und braucht weniger Strom.
Zum Strom: Das ist von SSD zu SSD unterschiedlich. Ich habe hier eine, die braucht mehr Strom als jede meiner 2,5" SATA-HDDs und eine andere ist sehr sparsam.
Keine Ahnung welche SSD du benutzt oder ob die kaputt ist, bei mir liegen SSD <0,5W, die HDD deutlich > 1,5W.
Auf jeden Fall genehmigt sich mein rpi Modell b mit LCD, SSD, HM-CFG-USB, RFXtrx und ner usv (Signalleitung über USB) 5,5W.
Zitat von: juppzupp am 08 Januar 2014, 07:08:04
Auf jeden Fall genehmigt sich mein rpi Modell b mit LCD, SSD, HM-CFG-USB, RFXtrx und ner usv (Signalleitung über USB) 5,5W.
Hört sich interessant an. Welche SSD, LCD und USV und USB-Hub sind angeschlossen?
SSD : Sandisk SDSSDP
LCD : http://forum.fhem.de/index.php/topic,12854.0.html
Hub : http://forum.fhem.de/index.php/topic,18165.msg122692.html#msg122692
USV : Eaton 3S
bei der USV, nicht das wir uns falsch verstehen. die hat bestimmt einen eigenverbrauch, den ich aber nicht zu den 5,5W gezählt habe. Das einfache anschliessen über usb, um kontrolliert runter zu fahren schlägt aber mit 0,2W zu buche. die sind in den 5,5 inkludiert.
Zitat von: juppzupp am 08 Januar 2014, 07:08:04
Keine Ahnung welche SSD du benutzt oder ob die kaputt ist, bei mir liegen SSD <0,5W, die HDD deutlich > 1,5W.
<0,5W brauchen die wenigsten SSDs. Meine sind alle deutlich performanter als eine Sandisk SDSSP und brauchen daher auch mehr Strom - natürlich auch am Pi.
Ich habe nun umgebaut auf einen passiven USB-Hub (< 3 Euro) + USB Speicherstick für Debian/FHEM und komme so auf unter 4,5W Verbrauch mit übertaktetem Pi und zwei Jeelinks. Das ist ok.
Hallo zusammen,
eine Frage im Nachgang: Wenn man das System auf eine SSD (oder was auch immer) erfolgreich umgezogen hat - kann dann die SD Karte aus dem Raspy entfernt werden oder wird die beim Booten auch weiterhin benötigt?
Danke an Alle und schöne Grüße
Hubertus
Raspberry kann natürlich nicht über USB booten.