V2.1 disk subpartition algorithm issue breaks install, also inescapable loop.

stilez

Clean 2.1 install.

Per sizing requirements, I used a 2 GB SSD module as the disk and 2 GB ram, fitting Pfsense sizing requirements.
Both easy and manual x86 installers couldn't cope and "broke".

Result and analysis:

The reason is that the installer picks impossible defaults for partitioning, if Pfsense is used in a scenario where HD demand is small but RAM demand is not. Additionally the installer traps in an inescapable loop on clicking "CANCEL" (see follow-up post).

Both easy and manual installers install (or suggest) an impossible default for the disk layout ('/' = * and swap=2GB, ie 100% swap), causing an immediate fail. Pfsense's sizing only needs a tiny SSD module 0.5 - 1 GB, but snort/havp/ram cache/tcp states/packages could easily need 1-2 GB RAM. All install scripts calculate swap rely on an old desktop/server rule of thumb ("swap should be 1x or 2x ram") which doesn't suit router firmware at all and easily breaks the installer.

Examples of 3 snippets showing essentially same logic (code seems to exist in 9 files listed at end):

From /usr/local/share/dfuibe_lua/conf/pfSense.lua

local swap = 2 * ram_cap
if ram_cap > (part_cap / 2) or part_cap < 4096 then
   swap = ram_cap

From /usr/local/share/dfuibe_lua/conf/FreeBSD-dist.lua

local swap_megs = 2 * ram_megs
if ram_megs > (part_megs / 2) or part_megs < 4096 then
   swap_megs = ram_megs
local avail_megs = part_megs - swap_megs
if avail_megs < 300 then
   return {}

From /usr/local/www/installer/installer.php (also omits 50% or 4GB check: always uses 2x)

$memory = get_memory();
$swap_size = $memory[0] * 2;
$first_disk = trim(installer_find_first_disk());
$disk_info = pcsysinstall_get_disk_info($first_disk);
$size = $disk_info['size'];
$first_disk_size = $size - $swap_size;

Issue seems to exist in:

[bsdinstaller]  \src\backend\installer\fn_subpart.c
[bsdinstaller]  \src\backend\lua\conf\BSDInstaller.lua
[pfsense-tools]  \installer\conf\pfSense.lua
[pfsense-tools]  \installer\conf\pfSense_rescue.lua
[pfsense-tools]  \installer\conf\FreeBSD-dist.lua
[pfsense-tools]  \builder_scripts\builder_profiles\vCloudBSD\copy_overlay\etc\rc.local
[pfsense-tools]  \builder_scripts\builder_profiles\pfDNS\copy_overlay\usr\local\share\dfuibe_lua\conf\pfSense.lua
[pfsense-tools]  \builder_scripts\builder_profiles\pfFTP\copy_overlay\usr\local\share\dfuibe_lua\conf\pfSense.lua
[pfsense-tools]  \builder_scripts\builder_profiles\pfPBX\copy_overlay\usr\local\share\dfuibe_lua\conf\pfSense.lua

Also the limit at App.conf.limit (BSDInstaller.lua etc) doesn't seem to be appropriately tested in 400_select_subparts.lua etc.

Possible resolution?

It needs considerable experience to judge what swap requirements the different platforms, uses, or hardware may need. Perhaps the installer should ask 2 or 3 basic questions of the user about the intended use scenario (as it affects filespace and ram/swap), before suggesting defaults or proceeding with the easy install. The current logic seems more oriented to desktops and servers, it's hard to imagine a dedicated router needing swap space that's calculated as 1x or 2x RAM. It's possible the scripts may not sufficiently "sanity check" the final values used in subpartitioning, against the installer's own minimum config value (App.conf.limit).

In simple terms, something like this seems better suited:

With small disk space <=2GB, the default should be (say) first <app.conf.limit>and 70% of the next 700MB to files (if it's that tight, then it has to be assumed by default the user has sized accordingly and there is adequate RAM, so we need to ensure file space doesn't fill up as a priority). Beyond that:
Calculate a default or necessary swap space, or a "highest sensible value" that the installer should suggest for swap, based on PFsense scenario needs, not as a multiple of ram. If the disk is large enough to hold both the ideal file tree and ideal swap size, all's good - set a ceiling on the default swap space and give the files *;
If the partition isn't large enough to hold both the ideal file tree and swap sizes, identify how much the file system needs and split the rest between file and swap in some sensible way.</app.conf.limit>

stilez

As mentioned, this also exposed a related bug in both the easy and manual installer.
If the default sizes are accepted (or a user enters a manual subpartition layout input that fails due to low size of a needed partition), the installer gets trapped in an inescapable loop:

- The subpartitions you have chosen were not correctly created and the primary partition may now be in an inconsistent state…
(Presumably instead of just "OK", the installer should ask if you want to CONTINUE anyway, EDIT the subpartition sizes, or CANCEL the entire action)
Click OK.

- WARNING: the / subpartition should be at least 244M in size… Proceed anyway?
Click <cancel>. It should cancel but appears to try and proceed anyway, and fails and loops:

- Execution of the command … install.disklabel failed with a return code of 1.
Click <cancel>. It should cancel but it loops as above:

- The subpartitions you have chosen were not correctly created and the primary partition may now be in an inconsistent state…
Rinse & repeat</cancel></cancel>

eri--

I pushed some reducing of the swap size to 64M for minidumps as a minimum.
So your issue should be fixed, please test with new snapshots.