Doing a 'Full Update' to the emonPi caused it to 'brick'


So I was trying to fix my emonTH (Problem with humidity reading on EmonTh v2 and I thought I should do a ‘Full Update’ to my emonPi in case it helped.

Unfortunately during the update there was an error (see below) and now the emonPi won’t start (Rasperry Pi OS won’t boot). Luckily I did a back-up but not sure what the best way forward, is there an easy fix?

Update Emoncms database

EmonPi LCD Update

Reading package lists…
E: Problem parsing dependency 21
E: Error occurred while processing njam (NewVersion2)
E: Problem with MergeList /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages
E: The package lists or status file could not be parsed or opened.
/opt/openenergymonitor/emonpi/lcd/./ line 13: pip3: command not found

  • reinstalling emonPiLCD.service
    Removed /etc/systemd/system/
  • installing emonPiLCD.service
    Created symlink /etc/systemd/system/ → /opt/openenergymonitor/emonpi/lcd/emonPiLCD.service.
    Created symlink /etc/systemd/system/emonPiLCD.service → /opt/openenergymonitor/emonpi/lcd/emonPiLCD.service.
  • Service ActiveState=active
    Stopping emonPiLCD service
    Display update message on LCD

Starting emonPi LCD service…

emonPi update done: Sat 12 Sep 11:23:47 BST 2020

Follow the instructions here emonSD-24Jul20 release

Thanks. Might try a new and bigger SD card, any recommendations? (another Sony??)

Sorry, no. Just don’t buy off eBay.

Got a 32gb Sandisk microSD card and an USB SDcard reader (Alxum) from Amazon. It is of correct capacity and speed (for a class 10 SD card) and the adapter seems to work fine so I am happy.

It was reasonably straightforward to burn the new emon OS onto the SD card and once in the emonPi, it was back to working and reading both emonTHs and local emonPi sensors and logging data.

Deided today to import from backup my old account that was on the old SD card. This is where things went wrong. Although it did say ‘Import from SD card Succesful’ at the bottom of the log screen, things were not right. The emonpi boots correctly detects CT and temp sensor, but then doesn’t show either readings on the LCD screen and the next screen over on the LCD just says “Waiting for commmunication…”.

Logging in remotely (had to reset my password using SSH as I had forgotten it) none of the inputs were ‘active’ and giving readings. Shutdown and turn on, still the same. I tried to press ‘Import’ again and this time it got worse again. I can’t even login on local network now , gives Error Message ‘Unknown Database ‘emoncms’.

Well, my new plan is to reflash the SD card with the new image and go from fresh. I have a worry that I won’t be able to sync perfectly my new local data logging set-up with the cloud emoncms account but will cross that bridge when we get to it. (or should i try import once more??)

Password reset links:
Troubleshooting - Guide | OpenEnergyMonitor (activate php routine to change passwrd)
Service Credentials - Guide | OpenEnergyMonitor (full of useful terminal commands and info)

Another morning spent trying to get my data backups onto the emonPi, and glad to say succesfully this time.

My first attempt was with the ‘Import from Archive’ option in the emonPi backup menu. This worked well on a backup I made 6 months ago, but sadly not on a recent backup. I think the problem with the recent archive is with the macOS or iPadOS operating systems zipping the .tar.gz backup when I send it to iCloud which makes the file unsuable for import after that. Don’t know why it does that but I will watch out for that going forward.

Luckily, I found a spare of that backup archive actually on the original SD card so I could use that instead for the import (what a lucky find). At this point I had switched to my linux Ubuntu laptop to avoid using the mac.

Password problems:
A fresh install of emonOS meant I registered again with a different username and password to access the backup options. I didn’t make a note of my old username or password needed access the emonPi at the time of the backups.

This means I had to access the emonPi via the SSH backdoor and change the password. The ‘passwd’ command is a bit confusing;

I ddin’t know how to change the user ID so it only changed the password for the backdoor (confusing). Instead I switched to the reset password tool and used that instead.

Import from USB SD Card adapter
Feeling I was now safe with a viable archive backup, I thought I would have a go at importing from the original SD card again. Last time it didn’t work and just bricked the installation. However, I never repaired the SD card before I tried this; (Import / Backup - Guide | OpenEnergyMonitor)

I thought I would try and run the fsck command using the emonPi so I plugged in the adapter with the old SD card with the potentially corrupted data. Back into the emonPi with SSH, I entered the command fsck.ext4 /dev/sda2 however I got an error saying no such file or directory. Using lsusb or usb-devices I was able to find out that the SD card adapter was connected, however not what the address was. I tried /dev/sdb2 however no good. Back to my linux laptop then to run fsck.

Back on the Ubuntu laptop, I used fdisk -l to list all attached devices. The SD card adapter came up at /dev/sdc. Running the fsck command on partition 2 and 3 on the SD card came back with no errors and both filesystems ‘clean’. Didn’t really believe this , so I added the modifier -f to the fsck command to ‘force’ a deeper check. That check came back with errors in both partitions in 'inode’s.

Great, SD card ‘repaired’. Now repeat the ‘import from USB’ backup back at the emonPi and, what a surprise, it works just fine. The SD card repair might have been the reason for it working the second time.

So now I have, a latest version of the emonOS and all my data on the system. I am back to where I was. This isn’t the end though because now I want to do upgrades. First thing first, make use of the extra space on the SD card by using emonSDexpand script.

A copy from the webpage, because sometimes it’s hard to find the info.
Note for If the image has been written to an SD card larger than 4GB the data partition should be expanded to fill the SD card to create sufficient space to import a backup. Do not use Raspbian raspi-config , instead connect via SSH) and run $ sudo emonSDexpand and follow prompts.

The latest has already been expanded to fit a minimum 16 GB SD card size. To expand the data partition further run: /opt/emoncms/modules/usefulscripts/sdpart/./sdpart_imagefile .

This page also has links to useful scripts, but sadly no direct mention of emonSDexpander. (GitHub - emoncms/usefulscripts: Some useful scripts for administering Emoncms accounts)

My plan is to have the new EmonTH I bought to take the place of the old one with the broken humidity sensor (Problem with humidity reading on EmonTh v2 - #5 by SteffanCook). However, the new EmonTH has a different node ID so I have to learn how to ‘serial’ connect to Arduino’s in order to change that setting, so that on the online emonCMS back up it looks like the emonTH was never replaced. I could just remember that the data is now at a different feed, but remembering stuff is fine until you don’t. So best to change it if I can (emonTx / emonTH configure RF settings via serial (released FW: V2.6 / V3.2))

I also want to have a look at a nodered install so I can get battery level warnings. I use eneloop Ni hydride rechargable batteries (that are great) but they do die pretty quickly after they drop to 2.0V. I probably need an alarm warning at 2.1V.

@TrystanLea - just in case its a typo - when you use the emonSDexpand scripts it says to wait for the emonPi to restart and then wait 20 minutes for the partition to be expanded. Once it’s complete then the emonPi will shutdown. After that the instructions say you have to wait at least “30mins” for the shutdown to finish, but do you mean 30 seconds for shutdown , or is this a special shutdown?

Sadly I didn’t find out until later, but the emonSDexpand command has broken my installation. It restarted as expected to start the process but guess it didn’t finish its partition expanding process (after 8 hours). I had to unplug it and sadly this has now caused the installation to break. I wonder if an fsck will fix it?

For what it’s worth, on the odd occasion that I’v had to move or expand partitions, I leave the SD card in the laptop (where it got flashed) and use GPartEd.

@SteffanCook, why do you need such a big card? Are you just wanting more space for data?

I wanted an SD card quickly - Argos (the nearest place I could get one ‘over the counter’) don’t do 16 GB cards. That’s why I have a 32 GB card in mine.

As reported earlier, I wanted to update an 8 GB card - getting the 16 GB image onto that was tortuous. It’s a lot easier to expand a partition on an SD card than to shrink it before you flash it.

1 Like

Easier to just run the scripts.

A script to shrink the partition before it’s flashed? :open_mouth:

That isn’t as easy as you’d think. Took me ages to script the additional partition and expansion as part of the scripted install.

TBH, If you are using anything other than a 16GB disk, use the scripts. Not much more effort than the SD Image to use and the partitions are sized depending on the card size (with a max 10GB data partition IIRC).

fsck process did not fix it. reflash with Etcher

I thought 32Gb was value for money as the 16GB was only a pound cheaper. might as well get bigger and then you will write to each sector less often.

Now I think about it maybe I should have gone for commercial or PRO grade SD card instead…

OK, things have taken a turn for the worse.
Importing data from USB broke my installation and I had to reflash the SD. Then pressing the Full Update button on the admin screen caused the installation to crash again (EmonHub stopped working this time).

I know that a freshly flashed image is working, but that doing anything that works on the SD card (import, update or SdExpand) has a very high risk of causing bricking. I assume that the code is good its just that the copy errors probably to the ext4 filesystem folders causes a fatal error (not an expert…)
Given the fragility, I am thinking that starting from freshly imaged cards is the only way forward. I hope that data recovery from backups is possible without using the emonPi however to be fair I havent had a problem with Import from Archive yet.

oh wait, even a freshly imaged file is not working anymore. The EmonHub is not working…

*Failed to start emonhub.service: Unit home-pi-data.mount not found.
waiting for emonpi to stop controlling LCD

Starting emonPi LCD service…*

Seems to be a change in the underlying OS has caused this.

I’ve updated emonhub with your patch, thanks @borpin, stable brach also contains latest changes.

1 Like