Installer fails with "out of swap space" when installing ZFS-on-root with less then 4 GB mem (10.0-RC4)

Mark Martinec Mark.Martinec+freebsd at ijs.si
Mon Jan 6 01:27:08 UTC 2014


I was playing with bhyve on 10.0-RC4, trying to install another 10.0-RC4 
into
a 16 GB ZFS volume using the network installation DVD. Mostly kept 
defaults,
except that I chose a ZFS-on-root installation. The amd64 host was given 
1 GB
of RAM on the first attempt, but failed. It fails on 2 GB RAM too, but 
succeeds
when given 4 GB of RAM.

It's a bit tricky to capture the failure reason, because the 
installation script
covers the underlying failure and just reports by the end of the 
'Archive Extraction'
phase:

   An installation step has been aborted.
   Would you like to restart the installation or exit the installer?

Nevertheless, capturing the output using a null modem on a bhyve's 
serial console
(/dev/nmdm) the failure reason is revealed:

Jan  5 03:20:10  kernel: pid 1496 (distextract), uid 0, was killed: out 
of swap space
Jan  5 03:20:10  kernel: pid 621 (devd), uid 0, was killed: out of swap 
space
Jan  5 03:20:10  kernel: pid 1176 (dhclient), uid 65, was killed: out of 
swap space
Jan  5 03:20:10  dhclient[1123]: connection closed
Jan  5 03:20:10  dhclient[1123]: exiting.
[1;24r[m[?7h[?1h=[?1h=[H[J FreeBSD Installer

So it seems that the gpt partitioning does succeed in creating the 
necessary
partitions including the swap space, but that swap space is not mounted
when the OS installation begins.

I'm sure that some percentage of virtual memory could easily be swapped 
out
with not much ill-effect on further decompressing and unpacking of files
and other installation steps. Seems unreasonable that 2 MB of memory is
insufficient for a plain OS installation on ZFS.

I understand that ZFS would be happier with more memory for heavy 
production
use, and that a modern real iron has much more than 4 GB of memory, but
virtualized guests are often dedicated to a single task and could do 
well
with 'just' 2 GB of memory, even if using ZFS.

So my suggestion is twofold:

- let the installer mount the available swap partitions before jumping
   into heavy installation work;

- avoid covering an underlying failure with a quickly-redrawn installer
   menu; at least some delay after a failure but before erasing the 
screen
   would be useful, avoiding the user to go to great lengths to be able 
to
   capture the failure reason.

Mark


More information about the freebsd-stable mailing list