Today I've implemented the dynamic loading of partman-lvm and partman-crypto only when there is sufficient memory available [1]. This should result in a better experience for installs where there is limited memory available.
In principle partman-md (RAID support) could be loaded in the same manner,
but I'm not sure if there is a real need to do so ATM (only 750kB installed
size for partman-md, mdcfg-utils, mdadm-udeb).
I was able to test this by including the new partman udebs in a businesscard
image (which was surprisingly easy using debian-cd). The tests showed that
about 7.5MB free memory is required when partman is started to successfully
use guided LVM partitioning.
I have not yet managed to do the restructuring of removing existing LVM
data. Hopefully I'll manage to do that tomorrow. Please wait with
reimplementation of removing existing crypto volumes until after that.
Cheers,
FJP
[1] Commit log entry:
Dynamically load support for LVM and crypto
Only load components for LVM and crypto support when there is
sufficient free memory. For crypto this only loads base support
components; additional crypto components will only be loaded on
demand.
Support for guided (encrypted) LVM partitioning is only loaded if
partman-auto has already been loaded (which it may not be for
lowmem installs).
The priority of partman-(auto-)lvm and partman-(auto-)crypto is
lowered to optional to allow dynamic loading by partman-base.
The dynamic loading is done from the main partman script instead
of an init.d script to avoid interference from anna's progress bar
with the init.d progress bar.
The limit of 7500kB for LVM is based on tests on i386 (VirtualBox
with 5GB hard disk); the limit of 11000kB for crypto is based on
the existing limit used in partman-crypto for loading additional
components.
signature.asc
Description: This is a digitally signed message part.
