Bug#743058: debian-installer: installer blocks expert users if /swap is not doubly encrypted
Package: debian-installer
Severity: normal
Scenario:
Perform a netinst install with at least one dm-crypt partition on an
OPAL compliant storage device.
The whole disk is hardware encrypted (due to being OPAL), and for
compartmental protection, a couple partitions are additionally
software encrypted.
Even though the "expert" install mode was used, debian-installer
(which is oblivious to the fact that an OPAL device is targetted)
steps in as a nanny, and lectures the *expert* admin on the dangers
of having an unencrypted swap space, and *forces* an abort. Experts
have no way to override this mandate.
Problems with this implementation:
* The installer presumes erroneously that the target storage device
is not OPAL compliant. So the admin is forced to doubly encrypt
the swap space. A smart installer would know if a device is OPAL
based on the model number. At a minimum, a simple installer
should at least have a bypass option for OPAL users.
* The admin is an *expert*, and should not be nannied. Expert mode
was chosen, and experts know what they're doing, by definition.
Workaround (painful!):
The workaround is both irritating and error-prone. The user must
opt to /needlessly/ encrypt the swap space to fool the dumb
installer in order to continue, and then go back and destroy the
swap configuration to undo the (excessive) encryption. Going from a
dm-crypt partition to a non-dm-crypt partition is currently
*experimental*.
It should theoretically be trivial to undo the encryption on a swap
area, but the following steps to eliminate an encrypted swap area
actually result in an unbootable installation:
$ swapoff /dev/mapper/hda2_crypt
$ cryptsetup luksClose hda2_crypt
$ sed --in-place '/hda2_crypt/d' /etc/crypttab
$ sed --in-place 's@/dev/mapper/hda2_crypt@/dev/hda2@' /etc/fstab
$ mkswap /dev/hda2
$ swapon /dev/hda2
Those steps are a boilerplate for workaround (assuming hda2 is the
swap partition). However, they're incomplete because rebooting
results in:
"lvm is not available"
and
"/dev/disk/by-uuid/<uuid of former swap drive> does not exist".
The author of this bug report is unclear how to recover from this.
Perhaps something like:
lvm lvremove hda2_crypt
is needed?
Ultimately, the author had to start over, and leave unpartitioned
space for a swap, but not create a swap at all. Then after
installation, a swap partition had to be created manually.
-- System Information:
Debian Release: 7.4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux <not sure>-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: