[SOLVED] Insufficient diskspace for update on OPNsense nano

[BertM]

We still had some pfSense small devices (SML20081D) laying around that we purchased from applianceshop.eu some time ago and decided to change them to OPNsense.
These devices initially had a 2G CF card that we replaced with a 8G card and wrote OPNsense-16.1.8-OpenSSL-nano-i386.img on it.
Obviously, the nano image uses only 4G, and divides this in two slices of 2G.

Booted the device, configured it, and attempted an update to OPNsense 16.1.12 via the web GUI.
That failed with the message that it had insufficient disk space.

To overcome this (at least for now), I connected my laptop running PuTTY to the serial port, logged-in and started a shell ( option 8 ).

To free-up some space, I removed log files and closed the shell.
cd /var/log
rm *.log
exit

Then I performed an Upgrade from console ( option 12 ) which succeeded.

So here are my questions:

• Will, in the future, a nano image be made available for 8G CF cards (split in two slices of 4G), so there is sufficient disk space?
• If 1 will not happen, would it be an idea to change the GUI to allow updates to be done in individual packages?

Kind regards,
Bert

[franco]

Hi Bert,

Nano updates are tricky. In your case the RAM is probably the limiting factor, because Nano has /var /tmp MFS enabled. Even with 512 MB RAM installed updates may get tricky when the box wasn't updated in a few months as the updates can amount to more than 100 MB. With 256 MB RAM it's starting to become impossible.

Short-term, there are two workarounds available:

(1) Set up a symlink from /root/my/temporary/storage to /tmp/opnsense-update so that updates will be pushed to the card, not RAM.

(2) Disable the /var /tmp MFS option under System: Settings: Misc. and reboot, switch the option back, upgrade, and reboot if not already done by the upgrade.

Mid-term, we should maybe either move updates to /root completely or make is behaviour selectable from the GUI. There were discussions for this. Obviously Nano would make a bad target for pushing all updates to the SD card by default. It's probably going to be another switch that is enabled by default on Nano.

Long-term, hardware must be upgraded. The question whether Nano remains a viable option in the future is to be researched.

I hope this helps.


Cheers,
Franco

[BertM]

Franco,

Thanks for the answer. The two options you mention are worth remembering, so I jot them down in my little notebook.

And ofcourse I realise that these Sense small devices (SML20081D) are under-powered, as they just run on an old ALIX board.
We just happened to have some of them laying around because on a number of locations we replaced them with Sense Ghz small devices (PFS20083D) that run on an APU board (AMD T40E APU 1Ghz Dual Core, 2Gb RAM and 16G SD card)

I just thought to put them at good use for a while.
They just have to service 4 or 6 internet kiosks, running Porteus Kiosk.
And believe it or not, these boxes with that old ALIX board running OPNsense can do 70Mbit up and down from WAN to LAN, albeit with 100% CPU load.
Good enough for now.

[franco]

Hi Bert,

I shall vow to address this before 16.7, I was not trying to make up excuses and apologise if it came across like that.

I've brought back Nano very early due to popular demand and kept it updated, even though there were a couple of challenges along the way that would shed a bit of doubt on having Nano in this day and age.

Let's keep it fresh and functional. It will not go away in 2016 in any case.


Cheers,
Franco

[franco]

I thought I added this earlier, whoops.

https://github.com/opnsense/core/issues/928

[franco]

I closed this just now, initial support may be in 16.1.14, but it needs more testing.

The caveat is that all Nano will now have to download upgrades to permanent storage. One for the team.

[franco]

So the OPNsense code is functional, minor change in the updater and a bit of a rework in the GUI boot code. But there is a problem with FreeBSD's package manager that was reported and solved a few days ago.

https://github.com/freebsd/pkg/issues/1424

Unsure about the final target of this change, but 16.7 in any case so it'll be in the latest Nano images then.