After many, many months of flawless operation I’ve found my emonPI had hung solid today. Completely unable to do anything with it. It wouldn’t read from the disk at all.
All seemed fine after rebooting, but it looks like it stopped writing to the data partition on Nov 26, and now I find that nothing will write to the disk. The writes cache on the RasperryPi, but no syncs to the disk actually commit any data. I get no errors from Linux or anything,
I’ve rebooted a few times now, and each time the disk is reset back to Nov 26.
Anybody else come across this issue?
It’s the SD card from the initial batch of kickstarter EmonPI, so I suspect it’s getting a bit long in the tooth.
I’m very sorry to hear. thanks for reporting. The kickstarter units were shipped in June 2015 so I guess that’s 2 years and 6 months of operation.
We have had emonPi’s dating back to this time which are still running ok on their original SD card. Maybe you have just been unlucky. Were you running a stock unit? Or has there been any changes made to the system?
How many feeds have you been logging and at what rate? I’m just trying to build up a picture of use? Is the SD card totally dead? Will it mount on a Linux PC?
All the emonPi SD cards run their root FS in read-only mode to do our best to limit disk writes. The log files are stored in a RAM partition and Emoncms feed data is written to the data partition in a controlled way.
Would you like me to send you a fresh SD card with the latest image (Oct 17)? Happy to do this free of charge if you DM me with your contact details.
Or you can just download the new image yourself and flash to a fresh SD card:
Thanks for the offer of a fresh SD card. That’s very kind. However I’ve already ordered one from the shop and I’m happy to make that admittedly small contribution in thanks for all your work. The emonPi has been a great bit of kit.
My unit is a stock unit with no changes to the system other than a few online upgrades to the initial image. It’s running vlow-write-8.5
I have 11 feeds. 6 update every five seconds, and the other 5 when the 2 TH’s manage to get through on the wireless - theoretically every minute.
The SD card appears to be essentially in read only mode. The system runs normally, but nothing is ever written to the SD card in reality. If you reboot, or force a cache clear then the data on the card just resets to what it was on Nov 26 when it stopped working.
There’s nothing special about that date, and I’ve done nothing to the machine for many months. It’s just sat there doing its job.
It’s interesting to read the RasPi issue thread. I wonder if this issue has been fixed or improved with newer version of RasPi FW updates? The new SD card image has much newer FW for the RasPi.
It’s hard to test if a certain brand or model of SD card is better than another since the time between failures is so long! As yet we have not had any failures with our test emonPi’s. In the past, before moving to using a read-only file system SD card, failures due to write wear were quite common.
Finally got around to trying the new SD card in the emonPi today, and it didn’t go quite as planned.
Firstly there doesn’t appear to be a backup/restore option on the GUI menus. That’s despite the backup module being on disk and linked in according to the instructions.
Therefore I did the restore of the backup file manually (generated from commit bdb5f49a60b45a3428dfa941cea92bcc095968d8 of the backup module on an emonpi-28May2015), and although the nodes seemed to come back, the phpfina feeds were not listed in the GUI on restore, and didn’t update on disk.
I rebooted the EmonPi, which restored the feeds in the GUI, but they were still not updating. I checked a few logs and the like, but couldn’t see anything obvious.
At that point I backed out and returned to the original broken SD card. The restore on the GUI failed as well, but after the manual import, feed writer was at least updating the phpfina data files. The GUI feed list was blank initially - even after logout and login - but after several hours the feed list has come back. (Which sort of suggests the blank list was being cached somewhere).
Any idea why the backup module isn’t appearing on the menus or why the restore of an old image backup would stop the feeds from updating?
Reguarding the backup menu option not shown, it may be this (copied from another thread)
Try scrolling down in the setup drop down menu, if it is like mine it will be below administration. It’s as if the menu is too short for all the contents. I use safari and it looks like the earlier poster did too, so could be specific to that.
Updated the backup module on the old card to the latest git commit, and it has stopped working for ‘old’ images.
=== Emoncms export start ===
Tue Jan 2 14:47:27 UTC 2018
EUID: 1000
Reading /home/pi/backup/config.cfg....
Location of mysql database: /home/pi/data
Location of emonhub.conf: /home/pi/data
Location of emoncms.conf: /home/pi/data
Location of Emoncms: /var/www/emoncms
Backup destination: /home/pi/data
old image
Log is turned off
Stopping feedwriter: stopped
Emoncms MYSQL database dump complete, adding files to archive ..
tar: Removing leading '/' from member names
tar: /home/pi/data/node-red/flows_emonpi.json: Cannot stat: No such file or directory
tar: /home/pi/data/node-red/flows_emonpi_cred.json: Cannot stat: No such file or directory
tar: /home/pi/data/node-red/settings.js: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Error: failed to tar config data
emoncms export failed
I’ve had another go at upgrading today when I had a bit more time. I had to setup all the processes from scratch as they didn’t import.
The problem with the feed page and the menu was down to the cookies/cache in the local browser for the pi. Once I cleared those they all popped back up again.
And yes the backup module is on the setup menu - and requires a scroll to get to it.
