Project

General

Profile

Actions

Bug #2867

closed

Subpartition algorithms can cause install to fail or subpartition defaults to be impossible, on installs with small HD + sizeable RAM

Added by Stilez y about 11 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Installer
Target version:
-
Start date:
03/11/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

Clean 2.1 install, but existed in 2.01 as well, and I'm guessing all.

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 = $memory0 * 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:
[code][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[/code]

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:

1) 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:

2) 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 *;

3) 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.

Actions

Also available in: Atom PDF