Hmm. I don’t have a usefulscripts directory under /home/pi… any tips?
pi@emonpi ~ $ pwd
/home/pi
pi@emonpi ~ $ 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:
pi@emonpi ~ $ 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 IP@) 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! 
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:
pi@emonpi:~ $ 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?