The location and size of the /tmp partition is defined in /etc/fstab (be very careful in there, get it wrong and the image might not boot). However, you only have 300Mb to play with on your main partition, where as the data partition is only 2% used.
You might be better off using gparted to resize and move the /data partition to give your FS some space before trying to accomadate the upgrade.
Thank you @Paul. Not being a particularly gifted Linux buff I’m unsure what tweaking would be required and your warning about the dangers of tampering with /etc/fstab/ is an echo of prior notes I’ve seen on the Web.
I’ll have a go at re-jigging the file and data partition sizes with GParted - once I’ve worked out to drive it.
/tmp is mounted tmpfs, so the limiting factor is the amount of available RAM vice the free space on the disk drive, as tmpfs exists in RAM vice on the disk drive.
Now that 1.7GB of free space is available on the root partition, the easiest thing to do would be use GParted to create a temporary partition from the free space - say 800MB, map it to /tmp, update Java, then undo the remapping and delete the partition.
For example, if the newly created partition is SDA2, the commands to map it to /tmp would be:
sudo mkdir /tmp
sudo mount /dev/sda2 /tmp
after the update is done,
sudo umount /tmp will unmount /tmp from the disk drive. sudo rmdir /tmp to delete the /tmp dir from the disk drive. Use GParted to delete the temporary partition and recover the space. Done.
N.B. the unmount command is umount. i.e. no n between the u and m. There shouldn’t be any need to change the fstab file.
Well aware of that Bill, hence my comments about fstab and question about size required, a simple edit of “30” to “150” would give 5x the space in /tmp, however the space on disc is getting low so I pointed that out too as installing more/updated sw will eat into that too.
I didn’t think you could mount a tmpfs to a partition as you suggest so that wasn’t my next move. I would have suggested just unmounting the ramfs /tmp partition so that the OS found the /tmp on disk underneath it.
rpi-rw
sudo umount -l /tmp
Other alternatives are to increase the tmp partition size or comment that line and reboot (undoing any edits afterwards) but I think unmounting /tmp is the way to go.
either way a simple reboot after the upgrade is done would restore things make to normal.
Correct.
I forgot that an unmount would be needed before mounting the temporary partition.
But… as you mentioned, simply unmounting the tmpfs mounted /tmp, to unmask the underlying /tmp dir on the disk drive would be easier and quicker by far.
I just tried the java -version command on a up to date Pi running Stretch and got this
pi@raspberrypi:~ $ java -version
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
so it looks like you do have a problem, why that might be I have no idea at this point.
You didn’t tell us why you were changing the Java version or what versions you have or wanted. Nor how you were upgrading it.
Did you check what was installed? To check it was working and to determine the version.
The reason I ask is that after determining what the current version in stretch was, I checked another older Pi and that was running the same despite being Jessie, I then powered up my old emonPi which is way out of date and that is running
pi@emonpi(ro):~$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode)
which looks to be a later version, this is significant because I now suspect the emonSD is not running the “latest stable debian package” and perhaps it was installed another way, I do not know offhand if that is definitely the case, the build guide might tell you more.
At the start of this thread I mentioned I was wanting to upgrade to Java 8 and had been using guidance at the link I’d indicated to achieve this. In hindsight it would appear I already had Java 8 installed, just a lot earlier version than current.
The java: command not found message occurred after the commands to remove the old Java 7 files were invoked, which, since Java 7 was not probably present presumably removed some of the Java 8 links in the process. Anyhow, after returning the /tmp configuration to original via a reboot I tried re-installing Java 8 again from scratch. The installation went off without a hitch and the java -version command now results in:
pi@emonpi(rw):~$ java -version
java version “1.8.0_161”
Java™ SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot™ Client VM (build 25.161-b12, mixed mode)
Having looked at the build guide I initially couldn’t see any reason for the later version, however I found that the included openhab guide upgrades to Java 8 and at first glance it seems to use the same method or at least the same source code repo as in your link.