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

kevin · 2016-10-26T06:24:02.782Z

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

glyn.hudson · 2016-10-26T09:39:29.467Z

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.

kevin · 2016-10-26T18:56:55.630Z

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.

kevin · 2016-10-26T20:16:45.496Z

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.

Andy_Taylor · 2016-10-26T20:35:15.227Z

@Kevin - that Andy Taylor bloke gets everywhere

glyn.hudson · 2016-10-26T21:07:20.005Z

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

github.com

openenergymonitor/emonpi/blob/master/fstab

tmpfs           /tmp             tmpfs   nodev,nosuid,size=30M,mode=1777 0  0
tmpfs           /var/tmp         tmpfs   nodev,nosuid,size=1M,mode=1777  0  0
tmpfs           /var/log         tmpfs   nodev,nosuid,size=50M,mode=1777 0  0
tmpfs           /var/lib/dhcp    tmpfs   nodev,nosuid,size=1M,mode=1777  0  0
tmpfs           /var/lib/dhcpcd5 tmpfs   nodev,nosuid,size=1M,mode=1777  0  0
tmpfs           /var/lib/openhab tmpfs   nodev,nosuid,size=40M,mode=1777 0  0
tmpfs           /var/lib/php/sessions    tmpfs nodev,nosuid,nofail,size=5M,mode=1777 0 0
proc            /proc            proc    defaults                        0  0
/dev/mmcblk0p1  /boot            vfat    defaults,noatime,nodiratime     0  2
/dev/mmcblk0p2  /                ext4    defaults,ro,noatime,nodiratime,errors=remount-ro 0 1
/dev/mmcblk0p3  /home/pi/data    ext2    defaults,rw,noatime,nodiratime,errors=remount-ro 0 2

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

kevin · 2016-10-26T21:16:36.710Z

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

borpin · 2016-10-28T22:06:22.123Z

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.

glyn.hudson · 2016-10-29T01:21:40.690Z

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

github.com/openenergymonitor/emonpi

Fix fatab to fix for latest raspi3 firmware and fix logrotate

committed 03:17PM - 28 Apr 16 UTC

glynhudson

+2 -1

kevin · 2016-10-29T23:05:14.258Z

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!

RaspberyPi php5-redis version emonSD

I’m updating my system which is based upon the February 2016 Beta Image, and back then there was a PHP5-redis version issue that prevented new feeds from being created. Can't create new feed - [SOLVED] | Archived Forum When I updated my first Pi it asked me which version of php I wanted, and as that Pi no longer runs EMONCMS I told it to use the package maintainers version. Is this the version to use on the EMONCMS machine,or do I need to keep my existing version to ensure everything works? U…

kevin · 2016-11-12T00:26:47.129Z

kevin:

sudo apt-get dist-upgrade

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