Restoring my backup brought back my feeds and graphs and what not. I had duplication of devices so I cleaned up.
My backup tarball only had a database dump and a few files - didn’t include the phpfine and phptimeseries directories.
So I copied them from /home/pi/data I think it was and guessed that they needed to go into the new /var/opt/emoncms.
Booting up after that there was a quite long time when the display showed Updating, but once done I seem to be back in business with my history intact.
Thanks for the help.
For others like me who haven’t dug into the detailed working - it seems that the ordinary update process in the web interface just updates the emoncms code itself and doesn’t update the underlying raspbian? Is that right? If so, what is the “proper” way to keep the OS up to date?
My backup did not include the I then shut down and copied the php… directories onto the 3rd partition. On booting up there was
I recall reading a thread some time back where updating the OS caused some things to break.
Is that still the case, or has that become a non-issue? i.e was that a problem with Jessie but
no longer an issue with Stretch or Buster?
Well - in case the perhaps naive expectation of a user/customer is relevant - I bought it as an piece-of-tin appliance so mentally did not distinguish the different parts of the firmware. It came with the SD card included and as a packaged turnkey device. So when I updated through the GUI I certainly assumed that the appropriate OS packages et al would be updated and I’d receive some sort of notification if I was on a dead-end software train.
Backups on my EmonPi failed since it runs out of space. I’m not sure which partition it makes the tarball on.
I see that the backup is made in /opt/openergymonitor/data which is on the small root partition rather than on the /var/opt/emoncms mount
The failed backup left a 632M tar file in that directory:
[email protected]:/opt/openenergymonitor/data# ls -lh
-rw-r--r-- 1 root root 0 Oct 17 10:42 dhcpd.leases
-rw-r--r-- 1 pi pi 632M Jan 14 13:14 emoncms-backup-2020-01-14.tar
-rw-r--r-- 1 pi pi 3.0M Jan 14 13:11 emoncms.sql
drwxr-xr-x 2 pi pi 4.0K Dec 7 15:46 import
drwxr-xr-x 2 www-data pi 4.0K Dec 7 15:46 uploads
It seems like a bad idea to generate the backup on the root partition and in the event of a failure the cleanup should probably be improved.
Not sure why you are being unpleasant to a customer who bought 100s of pounds worth of hardware from the project.
On the page which says “openhab used to be part of emoncms but is no longer included - here’s how to install it” perhaps a warning could be added to help others that says that installing it may fill up your root file system and cause operational problems for your emonpi. Or to make it clear you are going off-piste and are on your own.
I must say that I had forgotten that I installed Openhab.
Since the install instructions pointed to were openhab instructions I would not have assumed that the emonpi would update it.
Could you explaining for me though - on /admin/view page in the “Updates” section the default offer is full update with the description “OS, Packages, Emonhib, Emoncms & Firmware (if new version)”.
Does this include the OS? Seems to say that it does.
If you pop it down there is no separate option for OS.
What is included in “Packages”. Apologies if this is documented somewhere.
I am simply pointing out that assumptions are the mother of all &**%$ ups . Equally, you cannot say ‘it should work as I bought a complete system’ when you have then done modifications to that ‘complete’ system. Yes, the advantage of it is that you can change things but that comes with risks. This is also a community forum, not a commercial helpdesk. Majority of those who offer help do so in their spare time.
The OS bit may be a hang over from previous update scripts. I think the OS update part was dropped as it caused issues at one point with MQTT server versions.
A number of parts of the EmonCMS system are separate GitHub Repositories. This should probably be referred to as ‘Modules’ rather than ‘Packages’. At one time ‘packages’ like OpenHAB and Node-Red were pre-installed, but this became problematic so the practice was dropped and installing such things on the EmonPi comes with a caveat emptor . Your best solution is to run such things on a separate Pi.
On space for the root partition, that has been discussed, but there is a desire to maximise the space for data as that is the primary task of the EmonPi, so not an unreasonable design decision. Howver, the desire is to increase it for cards above 16GB - something I need to find time to do. Not putting the backup on the data partition was an error though.
IIRC it’s the other way round, it previously wasn’t doing apt-get update/upgrade until Trystan changed the update script to modularize it and the description was written as “update all” does in fact now do an apt-get etc where is has not previously (hence all the previous issues caused when users ran their own independent apt-get updates).