Archived Forum

Hello Paul, I found I needed to use at least ext2 with raspbian because raspbian requires the ability to set mixed permissions and ownership on files, could that be the problem I wonder?

If you can create an ext2 partition with a block size of 1024 bytes rather than default 4096 bytes that will better suited to emoncms, see the note here: https://github.com/emoncms/emoncms/blob/bufferedwrite/docs/install.md

But wouldn't that format be automatically created, as I've used dd to replicate the volumes from the SD card to the HDD?

Ah yes sorry, Im not sure what could be the cause, can you connect up a hdmi display to the pi to see if its giving any errors?

It does show errors, but I'm not sure what it all means;

--------------------------------------------------------------------

fsck: WARNING: bad format on line 7 of /etc/fstab

/dev/sda3: Superblock last mount time (Thu Jul 31 12:17:29 2014,
           now = Mon Jul 28 18:07:00 2014) is in the future.

/dev/sda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
    (i.e., without -a or -p options)
fsck died with exit status 4
failed (code 4).
[FAIL] File system check failed. A log is being saved in  /var/log/fsck/checkfs if that location is writable. Please repair the file system manually. ... failed!
[warn] A maintenance shell will be started. CONTROL-D will terminate this shell and resume system boot ... (warning).
Give root password for maintance
(or type Control-D to continue):

------------------------------------------------------------------

I've attached a keyboard, and have got a prompt. Looked at the error log 'checkfs' and it shows pretty much the same info as above.

Running $ sudo fdisk -l does list sda1, sda2, and sda3
and $ lsblk shows;

Hi Paul,

I've seen this a few times basically there's a time discrepancy between the time recorded on the boot partition and sda3, because the image was written on the 28th and that's the time it thinks it is at boot but the sda3 has a timestamp for today.

it's a daft system and not always easy to get around. sometime just running ctrl-d will work but other times not. the time it referencing is kept in /etc/fake-hwclock.data on the root partition, I have in the past just deleted the contents of that file so it has to look up the time and date.

Try ctrl-D if that doesn't work, try booting to an sd card, update the time, mount the hdd and copy over the timestamp ,

sudo fake-hwclock

sudo mkdir /media/hdd

sudo mount /dev/sda2 /media/hdd

sudo cp /etc/fake-hwclock.data /media/hdd/etc/fake-hwclock.data

Then reboot back to the hdd, it should no longer have an issue with the time difference, but there no guarantees :-)

Paul

Paul, Ctrl-D worked for me, and that appears to have resolved the issue, which has taken 3 days for me to sort out! - I wish I had posted earlier!

Just one other question, whilst locking the file system I get a message 'mount: you must specify the filesystem type', is that normal?

pi@raspberrypi ~ $ rpi-rw
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
pi@raspberrypi ~ $ rpi-ro
mount: you must specify the filesystem type
Filesystem is locked - Read Only access
type ' rpi-rw ' to unlock

Paul

 As you are booting to hdd you'll need to edit /usr/bin/rpi-rw and /usr/bin/rpi-ro to point to /dev/sda2 rather than /dev/mmcblk0p2, I've not seen it before but you shouldn't need to specify the file system.

Paul

Aaah, I think this error has been created because I only have the 'boot' partition on my SD card, and don't have the other two 'root' & 'data' partitions, and looking at the files you have highlighted, they were trying to access them on the SD card.

Does the emoncms guide need amending to include a change, as I assume we are currently probably wrongly locking & unlocking the file system on the SD card (when we should be locking/unlocking the file system on the HDD).

However, the flaw in this is that having changed both files to point to sda2, I still get the same result!

Paul

Sorry, i haven't tried running a hdd read-only so cannot speak from experience, have you tried writing to a file to confirm if it is RO or RW, I assume it's not RO although the message isn't explicit.

The guide doesn't' mention rpi-rw or rpi-ro, it should highlight the edits required if they are to be used on hdd, but it does mention switching the root partition to RW also.

Trystan may well be able to confirm from experience if rpi-rw/ro work with hdd image

Paul

Will it help if I delete /etc/fake-hwclock.data prior to creating the image? I could do that for the next update.

I've experienced the rpi-rw error too, sometimes it appears to just get stuck in write mode and gives that error. I think something must have a write lock.

Trystan - This should only be an issue if like Paul, users alter the image. If Paul had for example, just put the image on the hdd and booted to it, all the partitions would be equally time stamped and the time updated in due course. when he created his own partitions, new times were introduced by his linux live cd but not to fake-hwclock since it wasn't the os in use.

Changing partition sizes and adding partitions using a second machine, after running on new image on hdd should not pose an issue either as I believe there is an "ignored time difference" built in so if on returning to the pi a new partition is apparently dated 30mins in the future its ignored (that's from memory and I cannot recall if its 1hr or 1day etc)

I think this will crop up again, so it may well be worth pre-empting this in the image but I'm unsure of the "right" method you could try deleting the file and/or it's contents and see what messages you get booting with a screen to determine which is better a missing or empty /etc/fake-hwclock.data.

Paul - does the rpi-ro error still occur if you remove "errors=remount-ro" from the /dev/sda2 line of the /etc/fstab? Just a test not a solution I'm afraid. I have some distant memory of experiencing something like this when trying to lock the /boot partition sometime ago

Paul

Paul, yes the error still exists if I remove 'errors=remount-ro' from fstab.

...and rpi-ro does not prevent sda2 from being written to.

Is it necessary to keep sda2 as read only, and would ro interfere with other software such as node-red or my blog site installed in sda2?

Paul

There's no requirement to run it in read only mode, its just for peace of mind, to be sure that the os isnt doing lots of writing to a file that might cause sd card wear. As your running other things and your using a harddrive you might need to use read-write

If you want to revert to a fully RW system to re-enable caching and retain logfiles when rebooting etc the original files were  retained with a .orig extension when the "change to RO script" was run.

To revert the original fstab will need editing to boot to the hdd and also add the extra partition(s).

sudo nano /etc/fstab.orig

once you have made the fstab changes, to reinstate the originals (including the updated fstab), delete the rpi-ro/rw batch files and reboot, run

sudo mv /etc/default/rcS.orig /etc/default/rcS
sudo mv /etc/fstab.orig /etc/fstab
sudo mv /etc/mtab.orig /etc/mtab
sudo rm /usr/bin/rpi-rw
sudo rm /usr/bin/rpi-ro
sudo shutdown -r now

Paul

Just followed your post, and made the changes, and the kb_wrtn/s has understandably increased from 0.6 kb_wrtn/s to 3.06 kb_wrtn/s.

Paul

PS. I presume that I no longer need the temp volumes in fstab;
tmpfs           /tmp            tmpfs     nodev,nosuid,size=30M,mode=1777       0    0
tmpfs           /var/log        tmpfs     nodev,nosuid,size=30M,mode=1777       0    0

Correct, they were temporary locations set up in RAM at every boot-up, only needed because the main partition was RO.

Paul