Apt-get dist-upgrade breaks data partition- emonSD Feb16

emonSD
, ,
1

I’ve been running an image based on the February 2016 EMONPI image and just tried to update it with

sudo apt-get update
sudo apt-get dist-upgrade

unfortunately this stopped the pi from booting due to the OEM Data partition at /dev/mmcblk0p3 not mounting.
Removing commit=180 from FSTAB brings it back to life albeit without SAMBA working.

Has anyone else had this problem?
is commit= no longer relevant?
Is there anything else I should be doing instead?

Fortunately this is on my slave Pi which only runs Openhab, lirc and not EMONCMS. Restoring an older image brought it back, but it would be good to know what has gone wrong

2

Interesting, I have run dist-upgrade on the latest 08May16 emonSD without any problem (it seems).

The Feb16 release was a beta and never publically shipped. Please could you try using the 08May16 image and let me know if you experience the same issue: emonSD pre built SD card Download & Change Log · openenergymonitor/emonpi Wiki · GitHub

Be sure to run emonPi update via Emoncms interface before running dist-upgrade.

Moving your data should be no problem using the backup module that should pre-installed on both images.

3

Thanks for the reply. I’ll investigate the build guide. I use the same GPIO PIN in OPENHAB that is taken by the LCD so I can’t use the image as is.

4

Further reading, starting at the build guide has led me to this thread

https://openenergymonitor.org/emon/node/12566

and specifically this part

“The problem with the new firmware appears to be syntax related; “commit=120” on the line for the data volume in /etc/fstab is the issue. Reading from here: Ext2/Ext3 File System it looks like you are trying to use an EXT3 feature on an EXT2 filesystem, so removing the argument from /etc/fstab should have 0 effect (other than allowing the new 4.4 kernel to boot fully).”

which makes sense given that if I remove the commit line the thing boots again, and that is has gone from the version of FSTAB on GITHUB. Assuming I can get Samba to work again I have a working update which is way less work than rolling a new image.

I’ll now have another dig in case there is anything else that has changed between versions before I play with images again. From memory the image I made up from the build guide was pretty close to the released image which is why I didn’t change to it.

1 Like
5

@Kevin - that Andy Taylor bloke gets everywhere :slight_smile:

1 Like
6

Ah yes, the fstab in the emonpi repo is symlinked to /etc/fstab on the 08May16 image:

I’m not sure if this is the case with yours, probably not.

Yes this issue was brought to my attention and commit=120 was removed from the current emonpi fstab.

If you did want to use the new image you could just disable the emonPiLCD service from running, this would ensure the GPIO pin was not used. But I can understand that moving to a different image is more work than quickly fixing your current one! Nice work tracking down the issue :thumbsup:

1 Like
7

As ever its the initial response that gives a pointer to where to continue looking!

1 Like
8

Just as a general point, I do feel there needs to be some way (a Wiki perhaps) to capture all these little solutions for those that follow.

1 Like
9

This issue has been fixed back in April 16 for the official (non-beta) emonSD release: emonSD-03May16.

10

After changing FSTAB, I’ve sucessfully upgraded the machine. I also needed to reload SAMBA to restore Windows access to the Pi using

sudo apt-get remove --purge samba
sudo apt-get install samba

I also have a php version question which I’ve started a new thread about - thanks everyone for your help!

2 Likes
11

For anyone following later, Samba is broken as it needs write access to /var/cache/samba,
I cured this by adding the following line to FSTAB, and it now works in RO Mode

tmpfs           /var/cache/samba tmpfs  nodev,nosuid,size=40M,mode=1777 0  0

I also needed to create /var/log/samba and start the SMBD service after a reboot

1 Like