Permanent "Raspberry Pi Booting..." after failed emonPi Update

Emoncms
10

Good question! I don’t think it matters much right now, perhaps change it back just in case you forget it’s been done? But that means future updates will not work as your image is “unsupported” again, but it’s easy enough to deliberately change it if you need to update.

It will be interesting to hear what @glyn.hudson and @TrystanLea say on the matter. If it is just an incomplete “tested with” list, then perhaps the fact you have effectively tested the new update on the emonSD-07Nov16 image might mean they can add it to the repo version and next time you try an update, it will qualify even without fudging the version.

11

My EmonPI is on emonSD-07Nov16, and I am not sure what I should do now. Leave it as is, or update it in some specific sequence? As a layman, I am a bit lost with this. Not even sure where the SD card is. Any tips are much appreciated.

12

Hi Juerg, do you have SSH access to the emonpi? and are you ok with running a couple of commands from the command line? If so I can walk you through doing a update as Cristiano as done last week. the alternative is to wait and see if/when this gets addressed, I would of expected that to have happen already this past week or at least commented on by now, so I can’t say when that might be.

Since the 07Nov2016 image is not that different to the 26Oct17 image (ref image changelog) I’m unsure why it’s not included in the new safe list, but Cristiano seems to have had no problem (once the incomplete update was resolved again) so until I’m told otherwise I believe it to be safe.

First we have to change the version file so the updater thinks this is a later image, this can be done via the commandline without physically accessing the sdcard using this command

sudo mv /boot/emonSD-07Nov16 /boot/emonSD-26Oct17

then to avoid the issues Cristiano had due to the old updater script already having been triggered before all the file paths change, we do a manual update to just that repo so it should update ok first time.

git -C /home/pi/emonpi pull
[ $? -eq 0 ] && echo "EMONPI REPO UPDATED OK!" || echo "EMONPI REPO NOT UPDATED!"

The last line of the output should spell out if the repo was updated ok in capitals (to make it stand out).

(If for any reason this didn’t succeed then post the whole output here for us to check)

If it was “OK!” then run the “update all” from within emoncms and give it plenty of time to complete, you can watch the progress in the updater log window, when it is complete, post a copy of the updateemonpi.log here and I will take a look to see if anything looks iffy.

once it has been successfully updated we should probably put the image version back to what it was just to be safe

sudo mv /boot/emonSD-26Oct17 /boot/emonSD-07Nov16

but don’t do this last step until we know it’s ok just incase we need to run the updater again.

13

I’ve opened a couple of issue trackers on this to hopefully catch someone’s attention soon.

14

@CrisPastore are you happy that the update completed ok on the emonSD-07Nov16 image? It sounds like we should have added this image to the safe list and that I missed it by only testing emonSD-26Oct17. Im happy to add it in, I think @pb66 is right that the changes are minimal and should not affect a successful update.

I noticed in the discussion above a reference to broken paths and just wanted to clarify how the new update process works.

emonpi/emoncmsupdate is retained as a redirect so that the older images can access the newer update process, see: emonpi/emoncmsupdate at master · openenergymonitor/emonpi · GitHub

As part of the work on the new update process I also fixed the safe check, which was not previously working, it now makes a curl request to check the list of safe images: emonpi/service-runner-update.sh at master · openenergymonitor/emonpi · GitHub before running git pull on the emonpi repository here: emonpi/service-runner-update.sh at master · openenergymonitor/emonpi · GitHub

Unfortunately the first time the update process is ran on older images this check gets incorrectly passed as it is still the old implementation of the check, the emonpi repository is then updated. The rest of the update however does not continue, as the now redirected emoncmsupdate performs the safe check correctly. This avoids issues with a full emonpi update on an old image that is not safe to update but does mean the emonpi repo is updated which includes the emonPiLCD scripts - which is probably the reason your LCD showed booting.

Perhaps if someone else gets to the same point again it would be interesting to know if restarting the EmonPi gets rid of the Booting message and whether the rest of the system is otherwise not updated. I will try a test of this in the office next week.

15

@TrystanLea yes, so far I’m totally happy with my update on the emonSD-07Nov16 image.
My doubt now is whether should I take the time to flash a newer image or be worried that something similar will happen again on my next update.

Should you reccomend to switch to a newer image, there’s a way to get this done without disassembling my unit (by TTY perhaps)?

16

Good to hear that your happy that its working. I would hold off switching to the latest image for now. We are working on a completely new image based on an automated installer script, I think it would be better to switch to that once it is finished than go to the effort to switch twice, assuming your happy with your emonSD-07Nov16 updated system in the meantime.

17

Hi Paul,

Many thanks for the instructions. I should be able to apply that using my SSH. I hope to find some time tomorrow for this.

First though, it appears I will have to do these steps every time in the future before attempting to run ‘update all’ from within emoncms, correct?

If correct, it makes we wonder whether I perhaps should consider not updating anymore at all, and leave everything forever at the current state? After all, it does what it needs to, and I don’t seem to need new features or bug fixes. What are the drawbacks of not updating anymore?

Many thanks for sharing your insights.

18

Hello @Juerg1 we are looking into adding emonSD-07Nov16 to the safe to update list, so you should be able to update without the SSH changes. Most updates are feature or bug fix updates but there have also been security updates over the last couple of years that would be worth updating to keep your system secure (this is the main one I can think of: Important Emoncms Security Update from Nov 17).

1 Like
19

Thank you @TrystanLea, great news about planned updates to safe-list. I will happily wait till then.

Good to know about the security updates too. Of course, they are important, and a good reason to stay up to date.

For now, I will monitor progress on this post, and update my EmonPi when updates are again easy to do.

Many thanks to @Paul for the workaround too!

1 Like
20

Hello @Juerg1 Nov16 has now been added to the safe list, full details here:
https://community.openenergymonitor.org/t/upgrading-emonsd-07nov16-to-latest-via-emonpi-emonbase-update/11051

1 Like
21

Great, Thank you so much @TrystanLea.

22

Hi @TristanLea,
Finally, I ran the update to 10.0.2, and it completed with no glitches on EMONSD-07nov16.
Great, and thank you for supporting that SD image again.

After the update, I rebooted the EmonPi. When I go to the Backup page (thought a backup of the new version is a good thing to do), I get a lot of similar errors where the backup buttons and log window should be. The errors read:
Deprecated: Comments starting with ‘#’ are deprecated in /home/pi/backup/config.cfg on line 3 in /home/pi/backup/backup-module/backup_controller.php on line 25

The error repeats 12 times, with varying line numbers in the middle of the message, but always on line 25 at the end of the message.

How can I get the backup back to working order?

23

This is interesting! I’m not sure how that has gone undetected for so long!

Apparently the # symbol is no longer recognised as a comment line in php7.

https://www.php.net/manual/en/function.parse-ini-file.php

So the comments in backup/default.config.cfg (why it has a .cfg extn when it’s actually an .ini file I know not!) all need changing to use a semi-colon.

[edit] PR submitted

24

Very helpful @pb66, replacing the # with the semi-colons ; fixed it, - at least step 1 -, and the backup page is now displaying fine on the Emoncms page. Thank you!

However, when I try and start a backup, it seems not to like the new semi-colons at all. The following errors show in the backup/export log:

=== Emoncms export start ===
Sun  9 Jun 14:20:05 NZST 2019
Backup module version:
"version"      : "2.0.0"
EUID: 1000
Reading /home/pi/backup/config.cfg....
/home/pi/backup/config.cfg: line 1: syntax error near unexpected token `;'
/home/pi/backup/config.cfg: line 1: `; Emoncms Export and Import scripts config file'
Location of databases:
Location of emonhub.conf:
Location of Emoncms:
Backup destination:
emoncms backup module location /Modules/backup
Image version: emonSD-07Nov16
PHP Warning:  chdir(): No such file or directory (errno 2) in /home/pi/backup/get_emoncms_mysql_auth.php on line 27
PHP Warning:  require(process_settings.php): failed to open stream: No such file or directory in /home/pi/backup/get_emoncms_mysql_auth.php on line 30
PHP Fatal error:  require(): Failed opening required 'process_settings.php' (include_path='.:/usr/share/php:/usr/share/pear') in /home/pi/backup/get_emoncms_mysql_auth.php on line 30
Error: Cannot read MYSQL authentication details from Emoncms settings.php

Powered by OpenEnergyMonitor.org | low-write 10.0.2

I notice that my PHP is Version: 5.6.27-0+deb8u1 (Zend Version 2.6.0), but I would have no idea whether I should nor how to update PHP.

What should I do next to get the backup working again? Many thanks for your help.

25

Ah ok! Looking closer at it, it seems the config.cfg file is used by both the PHP code in emoncms and also the bash script that is run outside of emoncms via the service-runner.

What seemed like a simple deprecated comment symbol isn’t as straightforward as it would seem now.

Firstly why is this being thrown as an error on php5.6 if it only affects php7.x?

And secondly why is the file being read into emoncms as a ini using parse_ini_file() if it’s not strictly an ini file?

It is quite possible that this will get addressed as part of the new installer changes in the pipeline, otherwise, I think it’s probably the parse_ini_file() function that will need swapping out for something more compatible.

There’s a related discussion going on in the emonSD issues created using new scripts + emonhub environment file thread about using environment files.

I’m going to close my PR and raise an issue for this pending further discussion.

As a quick fix you mighty find that deleting all the comments works as it seems to be that the actual key value pairs weren’t considered an issue by either end.

[edit] Issue raised

26

This was only added recently (Commit) @TrystanLea.

27

That commit shows it being changed, but using the parse_ini_file() function pre-dates that commit.

In fact if you trace it back further it was introduced to the master repo in January

but was actually originally submitted by your good self in a PR back in February 2018

But we were still using Jessie (php5.6) back then, less so in January this year though.

Oh! And I just spotted the “tinkering” with php.ini using sed in the install script (and the hardcoded path for php7)

perhaps this could/should be done either in a drop-in to /etc/php/7.0/apache2/conf.d or maybe we could include the php directives in the new apache2 vhost?

ref 16.04 - Correct way to modify php.ini for Apache and/or CLI - Ask Ubuntu and PHP: How to change configuration settings - Manual

all 3 of those edited directives are available to set in either location, unfortunately AFAICT only one of the 3 can be set in .htaccess which might have been the ideal location.

1 Like
28

Ha, so I did :slight_smile:.

29

Thanks @pb66 for the explanations. It seems something much bigger now.

It raises the question of how many other ini/cfg files will be affected by this? I don’t know much about EmonPi, but I guess the Import feature and maybe many other functions are affected too? Crontab?

Is there a need or easy way to return to the previous version of 9.9.2?

Many thanks for the always helpful replies.