Older emonPi (pre May 2016) reset Emoncms local password

Hmm. I don’t have a usefulscripts directory under /home/pi… any tips?

[email protected] ~ $ pwd
/home/pi
[email protected] ~ $ ls
avrdude-rpi  data  emonhub  emonpi  RFM2Pi

No results when running the following from the root directory either…

sudo find . -name resetpassword.php

you will need to clone usefull scripts

cd /home/pi
$ rpi-rw
$ git clone https://github.com/emoncms/usefulscripts
$ php ~/usefulscripts/resetpassword.php
$ rpi-rw

Is the repo public, do you know?

I get:

[email protected] ~ $ git clone github.com/emoncms/usefulscripts
fatal: repository 'github.com/emoncms/usefulscripts' does not exist

Update: I downloaded the files via browser on my PC and transferred them across.
Slightly worrying that the filesystem is full - I had to put the scripts into /home/pi/data for the time being.

The full filesystem caused the update to fail. I’m not running anything on this other than the emonPi stuff. Any idea what might be hogging the disk space?

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       2.7G  2.6G     0 100% /
devtmpfs        459M     0  459M   0% /dev
tmpfs            93M  280K   93M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           186M     0  186M   0% /run/shm
tmpfs            30M  8.0K   30M   1% /tmp
tmpfs            30M   15M   16M  48% /var/log
/dev/mmcblk0p1   56M   20M   37M  36% /boot
/dev/mmcblk0p3  788M   46M  702M   7% /home/pi/data

Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
Starting emonPi Update >

Thu Aug 18 18:12:01 BST 2016

Update emonPi git:
fatal: write error: No space left on device
fatal: index-pack failed

Start emonPi Atmega328 firmware update:

Typo, should be;
git clone https://github.com/emoncms/usefulscripts

Yep! I assume your’e using a 4Gb SD card, which has little room for anything other than the basic emonpi image.
Probably time to buy a bigger card.

Paul

Sorry, typo has been corrected. If using a l larger card portion can be expanded using

rpi-rw 
cd usefulscripts
git pull
sudo sdpart/./sdpart_imagefile

Hmm, the script doesn’t seem to be working for me

It seemed to bork my system when run for the first time, and then after I gave up and flashed a new (May2016) image on the card (16GB Samsung class 10) and tried the script again, it seems to be borked again. I left it a good 90 minutes for it to sort itself out but the system did not power down on its own - it looks like it was hung, After reboot,SSH and local emoncms is unavailable.

Is there any other (reliable!) way to get the benefit of a larger card short of purchasing a pre-prepared 8GB from you?

Output from running the script, FWIW:

Filesystem is unlocked - Write access
type ' rpi-ro ' to lock

======================================================

Current Disk Info:

Disk /dev/mmcblk0: 14.8 GiB, 15819866112 bytes, 30898176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0003ea3e

Device         Boot   Start     End Sectors  Size Id Type
/dev/mmcblk0p1         8192  131071  122880   60M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       131072 7288831 7157760  3.4G 83 Linux
/dev/mmcblk0p3      7288832 7698431  409600  200M 83 Linux


======================================================

Proposed changes to be made:
 SD card total disk size = 14.7333984375Gb
 Data Partition size     = 11.2089848518Gb

Are you sure you want to proceed? [Y/n]
Filesystem is unlocked - Write access
type ' rpi-ro ' to lock
Created symlink from /etc/systemd/system/resize2fs_once.service to /lib/systemd/system/resize2fs_once.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/resize2fs_once.service to /lib/systemd/system/resize2fs_once.service.

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): Partition number (1-3, default 3):
Partition 3 has been deleted.

Command (m for help): Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (3,4, default 3): First sector (2048-30898175, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (7288832-30898175, default 30898175):
Created a new partition 3 of type 'Linux' and of size 11.2 GiB.

Command (m for help): Disk /dev/mmcblk0: 14.8 GiB, 15819866112 bytes, 30898176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0003ea3e

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1         8192   131071   122880   60M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       131072  7288831  7157760  3.4G 83 Linux
/dev/mmcblk0p3      7288832 30795776 23506945 11.2G 83 Linux


Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

This error message can however be disregarded, because your system
is about to be rebooted, and the new partition table will then be
read by your operating system.

Writing the resize2fs_once script


======================================================================

So far, so good... your system will now reboot and will then check and
expand your /home/pi/data filesystem to fill the resized partition.
THIS WILL TAKE UP TO 20 MINUTES OR SO
You will know when this has been completed, because your Pi will
poweroff and close down.
PLEASE dont be tempted to interfere with this process, because
it will likely result in a unusable filesystem.

======================================================================

Script output all looks correct. What happens when you power up the Pi
after letting the script run for about 20min?

I might be missing something here, but I don’t understand how increasing the size of the 3rd partition is going to help!

The issue appears to be that the filesystem has outgrown it’s partition (2nd partition) and both before and after the resizing script was run the size of the 2nd partition is 3.4G, only the 3rd partition has been increased from 200MB to a whopping 11.2GB, since only 7% of the original 200MB was used, surely this is unlikely to help.

EDIT - See this “RaspB+ and SD card Extend” thread on the old forum on how to increase the root fs manually starting with a new image before you do any updates. or if you have a second sdcard and USB micro sd card adapter you may be able to mount your choked SDcard and move the partitions that way. The former will be easier unless you have data to save (with only 14mb on the 3rd partition I guess it’s unlikely)

The device looks like it is booting up ok (display is alive and shows the build version, ethernet suggests that it’s been assigned an [email protected]) and there a few flickering LEDs inside the unit but having left it to its own business for a good 30 mins in case it was just slow at starting up, I don’t think there’s much going on.
No access via SSH or via web interface.

You may well be right - I was just following the suggestion without thinking too much about it. So, if what you say is true, surely there must be a significant portion of other ‘plug it in and forget about it’ users in the same boat as me? I haven’t done anything unusual (I don’t think) and yet the storage is maxed out…
Do you have a suggestion as to how I can avoid this issue in future (assuming I can breathe any sort of life into my unit!)?

Ahh I see you replied while I was hunting out an out thread, see my edit above.

PS what do you see now if you run df -h? or do you not have any access?

I’m not sure that this is currently the issue, as the script output suggests that the root partition remains at 3.4Gb in size, whilst the OS size of the May 2016 image is I believe less than 2Gb.

The available size of the root partition of the original SD card was 2.7Gb, which if over time has filled up due to updates, a few added programs, etc, etc, I could see the possibility of Josh running out of space. But this is a fresh image install, and is 3.4Gb instead of 2.7Gb in size.

@joshm, how did you format the SD card before writing the image

Paul

The error codes at the top of thread quite clearly state there is no space left, if the filesystem is 100% full at 2.7G and the partition was/is 3.4G then the filesystem was not expanded to fill the partition (resize2fs).

I cannot comment on what size the original image, root partition or filesystem where/are but for what ever reason the filesystem has choked and my point is enlarging the completely separate and barely used 3rd partition is not going to help.

Perhaps all it needed was a sudo resize2fs /dev/mmcblk0p2 before the 2.7GB limit was reached, why is there a limit at 2.7GB? Putting aside any larger sdcard options, it still seems like the image wasn’t properly expanded even to 3.4GB,

I think I used SD Formatter and I used Win32 Disk Imager to write the image.

Anyway: progress! :grinning:

It transpired that my SD card was somehow fried and stuck in read only mode - it was ok until I ran that script but hey-ho!
So I cracked open a new card that I had floating about and I’m now back up and running.
The data partition has 11GB free (not sure that helps with the disk full issue in the long term as @pb66 says) but at least I’m up and running again.

Thank you for all of your help @Paul , @pb66 and of course @glyn.hudson!

So this is how things look after setting up from scratch:

[email protected]:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.4G  2.2G  998M  70% /
devtmpfs        483M     0  483M   0% /dev
tmpfs           487M     0  487M   0% /dev/shm
tmpfs           487M  6.6M  481M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           487M     0  487M   0% /sys/fs/cgroup
tmpfs            40M  6.1M   34M  16% /var/lib/openhab
tmpfs           1.0M  4.0K 1020K   1% /var/lib/dhcpcd5
/dev/mmcblk0p1   60M   20M   41M  34% /boot
tmpfs            50M  1.1M   49M   3% /var/log
tmpfs           1.0M  4.0K 1020K   1% /var/lib/dhcp
tmpfs            30M   40K   30M   1% /tmp
/dev/mmcblk0p3   11G   33M   11G   1% /home/pi/data

It might be worth noting that my previous image was taken from a very early release (June 2015, I think). maybe back then the partitions were different sizes?