Bug#780769: debian-installer: monolithic images miss crypto components
Package: debian-installer
Version: 20130613+deb7u2 20150107
Severity: normal
Toying around with monolithic images made me (re?)discover that crypto
components are missing there. The reason seems to be their priority
(optional), meaning they don't get automatically picked up in the
pkg-lists/standard-udebs target & file, later included from the
build/pkg-lists/monolithic/common file.
I'm not sure what to do with it to be honest. Not touching the priority
and the standard-udebs generation would seem the best way for now, and
adding a few udebs to monolithic/common might make sense. But then, why
are those optional in the first place anyway? Looking at it, one can
see (e.g. partman-auto-lvm):
| commit 3df509c8b87451e3649cdc87ceecd53cd3e8cb2a
| Author: Frans Pop <fjp@debian.org>
| Date: Thu Dec 6 16:37:48 2007 +0000
|
| 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.
|
| r50370
Since monolithic images are meant to embed a lot of stuff, it might make
sense to add a few udebs below the #include mentioned above.
Mraw,
KiBi.
Reply to: