Archived Forum

This "feature" was a welcome side effect of the ntp-backup solution for the read only time issues on the sd card. Basically to save the current time it must "unlock" the read-only file system and then "lock" it again as read only. This does happen every hour from first boot.

As the read-only file sytem is intended to be left in a read-only state this side effect served the purpose of locking a file system accidently left unlocked by the user using rpi-rw (as you have discovered)

Forcing a file-system modified to run read-only to permanently override it's read-only status seems less than ideal and permanently reverting the read only changes may be worth concidering but if you wish to over ride the "auto-lock" then commenting out the "mount -t ext4 -o remount,ro /dev/mmcblk0p2 /" line in /etc/init.d/ntp-backup should do the trick, but be aware the intended outcome will then be reversed as each hour the file sytem will be opened to write the file and not locked afterwards so this will result in the file system never being read only for longer than 1 hour even if you use rpi-ro.

Paul

Hi Paul,

Thanks for the quick response. I have commented out that line and will see what happens in an hour. One thing I don't understand is that the line is as follows:

        mount -t ext4 -o remount,ro /dev/mmcblk0p2  /

 But my root file system is now the hard drive on /dev/sda1 so how is the above affecting that? I am pretty positive I am booting to the hard drive but will have a look around.

Can I also comment out the line that sets it rw mode as the file system should always be rw from now on? Or is it best to leave it there to avoid the failure of ntp-backup?

Finally, my understanding is that the rpi-rw / rpi-ro files are there to lock down and SD card  in the low-write scenario and so should be unnecessary when running from a hard drive using the full emoncms from git (which I forgot to mention, sorry!)

Thanks again,

BraileTrail

You have highlighted a potential issue with the ntp-backup as the root partition is indeed hardcoded to mmcblk0p2 which at the time didn't seem to be an issue as the read only modifications creating the need for this to be installed would only occur on a SD card, or so I believed at the time.

I will be interested in the outcome of your test too, as if you are running from hdd this file should have zero effect.

I struggle a little to understand why you have a read-only file system designed for use on an SD card especially when using the low-write version of emoncms whilst you are using a full version of emoncms on a hdd.

there are so many ways to configure things it's difficult to know what is important and easiest for you. i assume you want full emoncms and therefore a hdd, so you couls either install standard raspian without read-only modifications and install emoncms to that, or you could USE the read only raspbian os by putting all the files that need write access in a partition on the hdd as is done on the SD card image (ie mySQL and data feeds) so that the OS can be read-only as intended.

I think the key is to have the right tool for the job, read-only or not. There is a good argument for having a read only file system on the hdd to protect against accidents etc but it isn't as essential as with an SD card.

Paul

Paul,

I will be interested in the outcome of your test too, as if you are running from hdd this file should have zero effect.

Well it's been running for over an hour now with the change in place and the root file system is still read-write so it looks like it was successful from my point of view. I'll keep checking for a while and let you know if it does swap back to read-only. At some point I'll try a reboot too. But I too am confused as to exactly how the ntp-backup was working and affecting /dev/sda1.

I struggle a little to understand why you have a read-only file system designed for use on an SD card especially when using the low-write version of emoncms whilst you are using a full version of emoncms on a hdd.

 

Well...

I started out with my Pi2 booting to plain old Rasbian on the hard drive and I followed some instructions somewhere on the OEM site and installed a pre-packaged local emoncms using apt-get which all went well until I tried to upgrade it to full emoncms. The package installed with apt-get does not contain git repository data so I couldn't get any further that way.

I browsed the forum about installing full emoncms from scratch and that seemed "too hard"™ getting all the prerequisites in place. I then found the instructions here about installing the low-write image and upgrading that and away I went:

https://github.com/emoncms/emoncms/blob/bufferedwrite/readme.md

However I was having trouble keeping my WiFi card up, so I used a modified version of the WiFi_Check script from another post in the forums to try to keep the connection alive and to log the results to a file, what I found was that the cron output in the file stopped after about an hour and here we are.

I understand the safe-guards that having a read-only root file system can give but would still prefer not to have to enter rpi-rw each time I want to edit a file.

I may look at doing everything from scratch and putting more partitions in place so that I can keep the important bits of root safe but at the moment I'd rather get my system logging data.

Regards,

BraileTrail

Paul,

The root file system was back to rear-only after a reboot so I think I will bite the bullet and install from scratch.

From here https://github.com/emoncms/emoncms/blob/master/docs/LinuxInstall.md installing full emoncms from scratch looks long winded but doable but don't mention Raspberry Pi specifically.

But I also need to install and configure emonhub I believe and the instruction here https://github.com/emonhub/dev-emonhub are less encouraging in that it is for a development version:

Thanks,

BraileTrail

What is returned when you run " lsblk " at the command line ?

A read only file system will reboot to read-only the hack was only to prevent ntp-time reverting your use of rpi-rw.

I understand the safe-guards that having a read-only root file system can give but would still prefer not to have to enter rpi-rw each time I want to edit a file.

You can have a balance of both depending on what files you are editing. If you do not want any write restrictions ever, then you clearly don't want read only at all, I previously mentioned the emoncms data files on a write enabled partition, the same can be done for user docs or media etc. Protecting the system files doesn't mean everything needs to be read only, likewise being able to save a file to the users desktop doesn't mean leaving everything accessible.

Don't be put off by the term "development" with emonHub, that is the only version and the "dev"in "dev-emonhub" actually refers to the install locations and symlinking used to keep the files accessible IF you want to develop, dev-emonhub is the installer script I used during the development of emonhub and it hasn't been replaced yet.. You cannot get much simpler than copy, paste and run one line of code to install.

I have been working on a similar one line installer for emoncms but it's not yet complete and currently on the back boiler while I'm working on emonHub.

Paul

Paul,

Thanks for spending the time on this.

lsblk says:

root@emonbase:/home/pi# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 232.9G  0 disk
ââsda1        8:1    0    16G  0 part /
ââsda2        8:2    0     2G  0 part [SWAP]
ââsda3        8:3    0 214.9G  0 part /home/pi/data
mmcblk0     179:0    0  14.9G  0 disk
ââmmcblk0p1 179:1    0    56M  0 part /boot
ââmmcblk0p2 179:2    0   2.8G  0 part
ââmmcblk0p3 179:3    0   779M  0 part

I was a bit worried about the accented characters but a quick Google convinced me it was trying to draw lines to show sub-directory relationships.

You cannot get much simpler than copy, paste and run one line of code to install.

I think, strangely, that was the worry, there was so little to do compared with emoncms.

Thanks,

BraileTrail