extroot.sh.zip (1.5 KB)
For those who are running out of storage space on their vera and have an old SSD laying around, you can extroot the vera by moving the entire openwrt file system onto an the external drive.
I found in my case, that it was an essential step to stabilize the vera. Though I strongly recommend to do this with an SSD (which has built in RAM for cache and ECC), one could do this on a USB stick as well.
I do not like using the USB stick because they are slow (yes in spite of the USB2.0 interface limitation, most USB flash stick are even slower) and are failure prone. Indeed, they do not have wear leveling, Garbage collection and are made of lower grade NAND flash. So you are warned. Also I want to give a disclaimer that though this has worked wonders for me, I am not responsible for any loss of data or bricking. My script is quite safe as it should default back to loading from the onboard SLC NAND storage if the USB fails but you never know.
The process involves therefore a USB-SATA2 or SATA3 cable and an SSD.
Plug it to the USB port of the vera and
go into the vera settings/log section and enable logging to USB. The vera will initiate, partition and format the SSD and reboot. Your logs will be stored in the first partition which will be 512MB. There will be a second unformatted partition on the rest of the drive.
Once rebooted, ssh into the vera and run
df -h
You should see how much space you have on your drive (the overlay partition)
4. You can upload the script attached here with SCP and run it under SSH into the vera or SSH into it and run the commands from the script one by one.
5. The system should reboot at the end of the script so once it is rebooted (it may double reboot actually) SSH back into the vera and run
df -h
This should verify that you succesfully booted from the external SSD. For me it looks like this:
Notice the 55G available for the rootfs partition and 0% utilization. I ran this on a 64GB Crucial C300 drive.
One detail: the script should probably include a [tt]mkdir -p /mnt/sda2[/tt] prior to the mount. If the mount point doesn’t exist, the mount will fail and everything after will go down with it.
[quote=“parkerc, post:7, topic:199691”]Nice idea, thanks for sharing.
Will this cause any issues with firmware upgrades ?[/quote]
This depends a lot on whether the firmware upgrade involves an OS upgrade. Most don?t so it should not have any issues. I upgraded and downgraded between 7.0.27 and 7.0.26 and did not have any issues. The key is whether the fstab file gets changed.
Another wrinkle I just discovered is that there’s hardcoded path in the test/calculation for the maximum log file size in Vera’s script that handles log rotation (see /usr/bin/Rotate_Logs.sh). This causes the max log file size to always be computed based on the /tmp volume/mountpoint, rather than whatever volume is actually configured to store the logs, which is usually mounted below that at /tmp/log/cmh, and is in the script provided earlier in this thread. So, although you may have some large partition made available for logs, it does not appear that an individual log would come close, and the total size of all logs (including preserved rotated copies) would be only 10x that by default. My Plus has a 62M /tmp volume, so, for example, the maximum size of all log files would be 10 * (15% * 62M) = 93M, as no one log file copy would much exceed 9.3M, regardless of the size of my external log partition (default config is use max of 15% of /tmp for logs, keep 10 copies).
A fix for this would be to mount the log partition at /tmp instead of /tmp/log/cmh, a simple change to the fstab in the same way as rafale77’s other work in his script. This would also preserve other logs and may be quite useful when things go really pear-shaped, because even with an external USB, those still go to volatile storage (/tmp is a ramfs by default) and are lost on reboots otherwise.
Thanks Rigpapa. I had not noticed the tiny size of the logs. With the USB stick I had which was 16GB, I had always wondered why the max utilization of that partition was 10%.
Then edit the the Rotate_Logs.sh file (I installed nano on my vera so I used nano. I think you can use vi)
vi Rotate_Logs.sh
scroll down to find this section of the script:
# maxLogsDiskUsage is the number of KB.
if [ $maxLogsDiskUsage -eq 0 ]; then
# If we don't have a value defined in config for maximum size of the logs,
# we should allow them up to 30% of the /tmp/log/cmh size.
maxLogsDiskUsage=$(df | awk '{ if ($6 == "/tmp/log/cmh") printf("%d", $2 * 0.3) }') # KB
# In case something went wrong and we didn't get the 30%, define a static value.
[ -z "$maxLogsDiskUsage" ] && maxLogsDiskUsage=4096 # KB
fi
and change the folder to /tmp to /tmp/log/cmh like I did. I also increased the max size of the logs to 30% in the formula
Also works, of course, but does not preserve a number of other system logs stored higher up in /tmp across reboots.[/quote]
Well this did not work. changing the fstab to have the sda1 mounted on /tmp makes it fail to boot.[/quote]
The OpenWrt startup scripts (in /etc/init.d and /etc/rc.d) expect that volume to be mounted, and that’s usually done by preinit. The tmp filesystem is explicitly created and mounted by [tt]/lib/preinit/10essential_fs[/tt]. Commenting out the tmpfs mount and adding an explicit mount of sda1 there may be sufficient.
where something is mounted to the /tmp folder but it is a pivot root.[/quote]
Interesting. So my previous rec was based on 1040 on a Vera3 (7.0.27, the latest).
On 3232 (7.0.23 on Plus), the tmpfs is created in the function ramoverlay() in /lib/functions/preinit.sh, and then is later “pivoted” to the root by a call to pivot() in that same file. My inclination would be to comment out the mount in ramoverlay() and put your sda1 mount there. This is preferable to changing the pivot() function’s remount because that would leave the ramfs created by ramoverlay() unused and thus consuming memory that could be well-used elsewhere. Better still, rather than commenting out the tmpfs mount, make it the error condition if sda1 can’t be mounted (e.g. [tt]/bin/mount -t ext4 -o mode=755 /dev/sda1 /tmp/root || /bin/mount -t tmpfs …etc…[/tt]).
On 963 (7.0.22 on Lite), the oldest of the firmware I have running, the 10_essential_fs file is again used. That’s interesting. I would have expected that older firmware to be closer to 7.0.23 than 7.0.27.