I made the two changes in config.txt. There is no boot folder shown when I inserted the sd-card into my windows pc, so I simply changed x:\config.txt.
But this didn’t help.
The pi crashes after the first error that is thrown by a binding (mostly caldav, sometimes weather).
The macaddress in config.txt also didn’t work. The pi receives a new ip in every boot
I have another rpi3 with oh2 running. It’s my testing machine. It was setup with ua-netinst from 2017/03/17 but without any upgrade. So it runs OH 2.0.0 stable.
Can I move my configuration and my RaZberry zwave controller to that second machine? What do I have to do? As a first step I made a backup from /etc/openhab2 and /var/lib/openhab2 as described in the docs.
Is it possible to simply restore this to my second rpi? Do I have to update OH2 first to a 2.1.0.SNAPSHOT which was running on my crashed system?
Or should I download a completely new image and install that to another sd-card?
BTW: I am pretty sure that the rpi crashes during OH2 startup. tail -f /var/log/openhab2/openhab.log shows loading my rules, items and so on and also starts my init timer, loads some weather items and then freezes. Also there is no kernel panic during boot procedure.
IHello @ThomDietrich ,
sorry that I have to say, but this really drives me crazy. I set up a fresh sd-card with the normal setup as you described (not the ua-netinst!). Then I upgraded to 2.1.0.SNAPSHOT (latest binding) and - as described in the docs - replaced the conf- and the userdata with my last backup.
But OH2 won’t come up anymore. All I get in openhab.log is tons of these messages:
2017-06-12 23:57:19.595 [SCHWERWIEGEND] [org.apache.karaf.main.Main] - Could not launch framework
java.lang.RuntimeException: Error initializing storage.
Caused by: java.io.FileNotFoundException: /var/lib/openhab2/cache/org.eclipse.osgi/.manager/.fileTableLock (Keine Berechtigung)
at java.io.RandomAccessFile.open0(Native Method)
... 4 more
Please help as I do not know what I did wrong or how to fix this chaos.
What I saw is that all files have openhabian as owner. Maybe because I had saved them on my pc and restored them to home with my ssh client as openhabian . Is that wrong?
Hm, well, I must admit that I have seen the readme some months ago but forgot about it. Sorry and thanks for the hint! I will fix this.
Meanwhile I managed to mount the sd-card from the freezing pi with my Debian machine and had a look into openhab.log. The positions where it freezes are filled with some lines of NULL values. From watching the tail -f result it looked like the startup process always freezes at the same position. But that’s only because everything happens so fast and is not the truth. From looking into the log I can clearly see that it’s only around the same position.
Could there be another process from outside OH2 running which then fails? On the other hand there’s only OH2 running and owncloud.
Had to remove “console=tty0” from /boot/cmdline.txt and set “dt-overlay=pi3-miniuart-bt” in /boot/config.txt instead of “dtoverlay=pi3-disable-bt”.
I changed both at the same time before reboot, so I do not know if both or only one of the changes did the trick.
BTW: There is no /etc/inittab file in my system and therefore I skipped this step.
Sorry for the late reply. All of these and more things are actually done via the menu entry openhabian-config -> Serial Port. You could have saved yourself the trouble…
Does everything work now?
I hope I do remember every detail:
The first problem was that the controller thing reported /dev/ttyAMA0 as not existing.
I saw that /dev/ttyAMA0 belonged to root:tty and the permissions were 620 (!!!). Therefore I did
sudo chgrp dialout /dev/ttyAMA0
sudo chmod g+r /dev/ttyAMA0
In /boot/config.txt I commented out the line "dt-overlay=pi3-miniuart-bt" and inserted "dtoverlay=pi3-disable-bt".
sudo systemctl restart openhab2.service
This led to the following status shown by the controller thing: “OFFLINE - BRIDGE_OFFLINE The controller is offline”
I removed and set again the three options on openhabian-config under Serial Port and rebooted. No change, same status for the controller.
Then I reverted the above changes in /boot/config.txt and also removed “console=tty0” from /boot/cmdline.txt. After a reboot everything worked fine.
I received so much help from this forum. So I am happy if I could return a little bit to this great and amazing project.
No, I did not see the announcement. So thanks for your hint! The announcement sounds that there is a lot of very useful stuff and I think I will take some time the next days and install the newest version.
Maybe you can answer a question that is a little bit off-topic. Before the test I reported about, I tried to make a copy of my rpi sd-card using dd on my Debian machine. When dd was finished I put the card back into my rpi, but it did not boot any more telling me something like card was busy (“mmcblk0: card never left busy state” and “mmcblk0: error -110”). That’s only for the backgorund.
Later I saw in openhab-config the option “Move root to usb”. Does this option help reducing the number of read/write access to the sd-card? I am asking this because the web is full of rpi users complaining about broken sd-cards and also the card mentioned above is my second broken card within the last 3 years of using Raspberry PIs. It is said that a high number of read/write access reduces the lifetime of sd-cards.
Don’t waste your time. I set up a new sd-card with a fresh openhabian and solved the problem this way. I only mentioned this point just to give the background for my question regarding crashing sd-cards in general.
Thanks therfore. That was the point I was interested in. I will care for improving my backup strategy and also order a ups for my rpi.
Only 2 SD-Cards in 3 years? You are lucky.
It is not a matter of unclean shutdown, powerloss, bad power supply or wear leveling, but in many cases the Raspberry Pi eats SD-Cards which are fresh and new after a short while (in may case the file system git corrupted in the process of the firts apt-get update after installing the OS image.
The best one can do is exactly moving to usb sticks or usb harddisks.
Do you have scientific proof for that?
As I said in my linked comment, of course SD cards can fail eventually. But you should look at the hard evidence: 48 MByte/h - that’s the write rate I saw in mean over the course of one week on my productive system. Do the math. Everything else depends on the sd card product you are using and the steady operating environment.
To be fair, the developers of the raspberry firmware did their best to improve the SD-Card handling.
But what I understood was, that they handle different SD-Card differently. Some operation like ERASE, which is leggit on all cards, improve performance on some while loose information on others leading to corrupted file systems.
Allways update your raspberry pi firmware to the latest.
If you follow the advice to buy some supported cards you are ‘only’ affected by wear leveling.