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