'Low write load' image on HDD

Having nuked 3 SD cards I moved my system to a USB HDD about a year ago, and it ran well, except after about 9 months I started getting disk errors, which eventually prevented me from running a dd backup routine.

Eventually, at the weekend, the whole lot ground to a halt, I couldn't access it via IP or SSH, and upon checking the HDD, I found lots of serious problems, so I decided to start again, using the new 'low write load' image.

However, despite getting the system to function via the SD card, I'm struggling getting it to run via a USB HDD.

The process that I followed was to start with a 8GB SD card with the 'low write load' image installed, and which worked OK when booted, and allowed me to SSH in the the Pi and also via it's IP. So far so good!

I setup my USB HDD as follows via my windows laptop running a Debian Live disk;

  • sdb1 = a backup & storage volume, holding about 40GB of pre-existing data not associated with emoncms.
  • sdb2 = a 10GB FAT32 formatted volume (to house the emoncms root files.
  • sdb3 = a 10GB FAT32 formatted volume (to house the emoncms data files.

Firstly, I replicated the volumes from the SD card to the HDD using $ sudo dd if=/dev/sdc2 of=/dev/sdb2 bs=4M and $ sudo dd if=/dev/sdc3 of=/dev/sdb3 bs=4M and which seemed to go well, no errors reported and I could see the various files in sdb2 & sdb3 which were now listed as ext4 & ext2 format respectively.

I edited the HDD /etc/fstab to show sda2 & sda3 (the allocated volume addresses by the Rasp Pi), and also the cmdline.txt on the SD card to show sda2 as 'root' as per the guide.

But when I assemble the Raspi and HDD, emoncms is not accessible via IP or SSH, although the 4 Raspi's LEDs are lit and the RFM2PI LED flashes every few seconds.

....very close to reaching for my 7lb hammer and starting a new hobby!

Paul

TrystanLea's picture

Re: 'Low write load' image on HDD

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

Paul Reed's picture

Re: 'Low write load' image on HDD

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

TrystanLea's picture

Re: 'Low write load' image on 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?

Paul Reed's picture

Re: 'Low write load' image on HDD

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;

NAME MAJ/MIN SIZE RO TYPE MOUNTPOINT
sda1 8:1 813.9G 0 part  
sda2 8:2 9.8G 0 part /
sda3 8:3 9.8G 0 part  

 

pb66's picture

Re: 'Low write load' image on HDD

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 Reed's picture

Re: 'Low write load' image on HDD

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

pb66's picture

Re: 'Low write load' image on HDD

 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

Paul Reed's picture

Re: 'Low write load' image on HDD

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

 

 

pb66's picture

Re: 'Low write load' image on HDD

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

 

TrystanLea's picture

Re: 'Low write load' image on HDD

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.

pb66's picture

Re: 'Low write load' image on HDD

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 Reed's picture

Re: 'Low write load' image on HDD

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

TrystanLea's picture

Re: 'Low write load' image on HDD

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

pb66's picture

Re: 'Low write load' image on HDD

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

Paul Reed's picture

Re: 'Low write load' image on HDD

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

pb66's picture

Re: 'Low write load' image on HDD

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

Paul

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.