pfSense

We can't remove the check entirely but it would need to be adjusted for whatever limits tmpfs may have. For example, total non-kernel memory size, with some allowances for system processes and so on.

But that's not something we'll be doing for the next Plus release yet, better safe than sorry here for the time being.

Note to self: tmpfs data can get moved to swap under memory pressure, which further extends its potential capacity, so we may also want to factor in available swap size into any limitations here.

https://man.freebsd.org/cgi/man.cgi?query=tmpfs&apropos=0&sektion=0&manpath=FreeBSD+14.0-CURRENT&arch=default&format=html

Applied in changeset 5f43b9b527a6a65bd2c70ac231e3fdceff6ab0d3.

Looks like there is still a problem here. The memory calculation in source:src/etc/rc.ramdisk_functions.sh is still using kernel memory only to compare, it needs updated the same way that the GUI code was updated.

There is a chicken/egg problem here that will need more time to solve properly to allow creating RAM disks at boot that utilize swap space due to their size.

I can update the calculation so it accounts for swap but at the time RAM disks are mounted during boot, swap is not yet configured. But we can't configure swap before mounting the drives because when configuring swap, before using it, it needs to be able to run savecore to store crash dumps in /var/crash, but var may not be available because it should be a RAM disk. So either the calculation in the shell script will need to be more creative (checking partition sizes, not active swap sizes) or we'll need to figure out a way to reorder the boot process. If we change the calculation, existing RAM disk contents may not fit because swap isn't available yet.

Moving swap initialization up higher seems better, but that would mean changing where savecore puts the crash dumps.

The last commit, b10998b1951b3e0d1cb74449a6b6dd333b9d292a, did not work on some systems and triggered a boot time failure of RAM disk initialization, so that commit has been reverted for the time being.

This appears to be due to swap not being configured yet, the variable is ending up empty and the calculation is failing:

# echo $MEM_FREE
805548032
# echo $SWAP_FREE

# MEM_FREE=$( /bin/expr \( ${MEM_FREE} + ${SWAP_FREE} \) / 1024 / 1024 )
expr: syntax error

Probably needs a test above there to only add those together if swap is non-empty.

Needs more time to come up with a proper solution.

Since the only real affected platform is EOL and this doesn't seem to be a widespread issue, it isn't a priority. If we find a safe and accurate way to do it later we can pick it back up.