/tmp too small



  • I'm using a nanobsd 2.0.2.
    I've tried 1G and 4G, but in both cases my /tmp is too small.

    I've installed Squid and SuidGuard. When I try to load a blacklist provided by this university, pfsense copy and untar the file in /tmp.
    Unfortunately 35MB is too small for that task.

    I've tried to create a symbolic link from /tmp to / (where I have much more space), but this link is just temporary and desperate after the next poweron of pfsense.

    Is there a solution I've not yet think about ?
    Is there a possibility to make permanent changes (for example create the link in /tmp) ?

    Thanks for your answers



  • /tmp and /var are memory disks on nanobsd. They get created from scratch by the boot scripts. Whatever is in them at shutdown goes in the bit bucket (things like RRD data can get saved at regular intervals to the real CF card).
    So it doesn't matter how big your CF card is!
    There have been some mentions of making the /tmp and /var memory disk sizing settable from the WebGUI - that would help people who have plenty of memory in their nanobsd system, they could get more space in /tmp and /var.
    At present you have to find where it is set in the boot scripts and edit the magic numbers.



  • @william_os4y:

    I'm using a nanobsd 2.0.2.
    I've tried 1G and 4G, but in both cases my /tmp is too small.

    you have only an 4G CF card/USB Stick and want there use squid?
    If not it's best to use memstick image like "pfSense-memstick-2.0.2-RELEASE-amd64.img.gz"
    or the installer ISO like "pfSense-LiveCD-2.0.2-RELEASE-i386.iso.gz"

    And you should decide if you can/want amd64 or i386 architecture.

    Or if you want run pfsense on nanobsd image and have another HDD for squid you could use the

    Shellcmd Services Beta 0.5 platform: 1.2 The shellcmd utility is used to manage commands on system startup.

    package to get your symlink created at boot.

    Bests



  • @phil.davis:

    /tmp and /var are memory disks on nanobsd. They get created from scratch by the boot scripts. Whatever is in them at shutdown goes in the bit bucket (things like RRD data can get saved at regular intervals to the real CF card).
    So it doesn't matter how big your CF card is!
    There have been some mentions of making the /tmp and /var memory disk sizing settable from the WebGUI - that would help people who have plenty of memory in their nanobsd system, they could get more space in /tmp and /var.
    At present you have to find where it is set in the boot scripts and edit the magic numbers.

    Thanks. I've found it in /etc/rc.embedded.

    it's called tmpsize.


Log in to reply