Package: debian-installer
Version: 20150324

When using a current jessie installer cd-image to set up a LUKS (random
key) encrypted partition for swap, it will not mount. It does show up in
/etc/fstab correctly, but the DM device is not automatically created at
boot time.

Control: tags -1 unreproducible

I have tried to reproduce your problem, but have not been able to
do so.  I have used the follwing installer image:

http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/20150324/images/netboot/mini.iso

and have run an installation in a VM with the following partition
layout:

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048   976895   974848  476M 83 Linux
/dev/sda2         978942 16775167 15796226  7,5G  5 Extended
/dev/sda5         978944 14649343 13670400  6,5G 83 Linux
/dev/sda6       14651392 16775167  2123776    1G 83 Linux

sda1 is the /boot partition
sda5 is a LUKS volume with passphrase, used as root filesystem
sda6 is a LUKS volume with random key, used as swap partition

This results in:

root@debian:~# cat /etc/crypttab
sda5_crypt UUID=16357360-c97c-4b6b-89bc-3bdebe8f4406 none luks
sda6_crypt /dev/sda6 /dev/urandom cipher=aes-xts-plain64,size=256,swap

root@debian:~# ls -l /dev/mapper
insgesamt 0
crw------- 1 root root 10, 236 Mär 27 15:21 control
lrwxrwxrwx 1 root root       7 Mär 27 15:21 sda5_crypt -> ../dm-0
lrwxrwxrwx 1 root root       7 Mär 27 15:21 sda6_crypt -> ../dm-1

root@debian:~# grep swap /etc/fstab
/dev/mapper/sda6_crypt none            swap    sw              0       0

root@debian:~# free
             total       used       free     shared    buffers     cached
Mem:       4057012     110800    3946212       8564       8672      48812
-/+ buffers/cache:      53316    4003696
Swap:      1061884          0    1061884

Control: tags -1 unreproducible

I have tried to reproduce your problem, but have not been able to
do so.  I have used the follwing installer image:

http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/20150324/images/netboot/mini.iso

and have run an installation in a VM with the following partition
layout:

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048   976895   974848  476M 83 Linux
/dev/sda2         978942 16775167 15796226  7,5G  5 Extended
/dev/sda5         978944 14649343 13670400  6,5G 83 Linux
/dev/sda6       14651392 16775167  2123776    1G 83 Linux

sda1 is the /boot partition
sda5 is a LUKS volume with passphrase, used as root filesystem
sda6 is a LUKS volume with random key, used as swap partition

This results in:

root@debian:~# cat /etc/crypttab
sda5_crypt UUID=16357360-c97c-4b6b-89bc-3bdebe8f4406 none luks
sda6_crypt /dev/sda6 /dev/urandom cipher=aes-xts-plain64,size=256,swap

root@debian:~# ls -l /dev/mapper
insgesamt 0
crw------- 1 root root 10, 236 Mär 27 15:21 control
lrwxrwxrwx 1 root root       7 Mär 27 15:21 sda5_crypt -> ../dm-0
lrwxrwxrwx 1 root root       7 Mär 27 15:21 sda6_crypt -> ../dm-1

root@debian:~# grep swap /etc/fstab
/dev/mapper/sda6_crypt none            swap    sw              0       0

root@debian:~# free
             total       used       free     shared    buffers     cached
Mem:       4057012     110800    3946212       8564       8672      48812
-/+ buffers/cache:      53316    4003696
Swap:      1061884          0    1061884

Hi Karsten:

Am 27.03.2015 um 15:57 schrieb Karsten Merker:
closer look. Meanwhile I figured out what went wrong:

I installed from a cdrom iamge on a KVM/QEMU virtual machine with cdrom
as well as target storage connected via a virtio-scsi controller.

(Snippets from the libvirt vm definition xml:
[...]
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04'
function='0x0'/>
    </controller>
[...]
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/lxc.img'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='1' unit='0'/>
    </disk>
[...])

The early installer stage does not find the CD it's installing from nor
the target storage, until I connect a virtual USB drive containing
virtio-modules-3.16.0-4-amd64-di_3.16.7-ckt2-1_amd64.udeb. The USB drive
then becomes sda, then the virtio-scsi ctrl is found, including the
cdrom and making the target storage become sdb. The installer generates
(fs|crypt)tab referencing sdb, but on next reboot w/o the USB drive,
target storage becomes sda.

Not sure if it would work O.K. with LVM, b/c I partitioned like this:
/dev/sda1                               ext4 /boot
/dev/sda2 (encrypted with /dev/urandom) swap
/dev/sda3 (luks encrypted)              ext4 /

I fixed my vm by rewriting (crypt|fs)tab, referencing partitions in the
/dev/disk/by-id/... style, and running update-initramfs -u using a
rescue system (called grml, fwiw).

Probably I could've worked around this installer bug using a floppy
drive for the udeb instead of a usb drive, at the cost of having to add
a virtual floppy drive. Does anyone voluntarily use floppies (even
virtual ones) in 2015? Not sure if win. ;)

I suspect that every machine is affected whose storage controller is not
included in the installer if it's installed with encrypted partitions
when the user chooses to use a /dev/sdx drive that is detected before
the fixed storage. (Or just when some sdX drive happens to be present
prior to the /dev/sdX target storage for any reason, probably even if
installing from USB)

A good fix would be to make the installer generate (crypt|fs)tab
referencing all drives in a better suitable way; I'd recommend by-id.

Do you still need any of that? I'd reproduce IOT help troubleshoot.

Sry I can't recall that, but I'm now trying rc2 from
http://cdimage.debian.org/cdimage/jessie_di_rc2/amd64/iso-cd/debian-jessie-DI-rc2-amd64-netinst.iso
(md5sum 82d3ff6d2422af72f5e1a82de88c21ea)

cheers

Am 27.03.2015 um 21:48 schrieb Kevin Price:

The problem is also in rc2.


/etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sdb3_crypt /               ext4    noatime,errors=remount-ro
0       1
# /boot was on /dev/sdb1 during installation
UUID=eef65a61-8310-44d5-a3fc-5692c3dcd464 /boot           ext4
noatime         0       2
/dev/mapper/sdb2_crypt none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0


/etc/crypttab:
sdb2_crypt /dev/sdb2 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sdb3_crypt UUID=64b58af0-e652-4134-8637-20a0843a5c49 none luks

Control: assign -1 partman-crypto

Thanks for the additional information. I assign the bug to the
partman-crypto package which creates the crypttab entries.

No, with the further information you have supplied the source
of the problem is clear.

Regards,
Karsten

Control: assign -1 partman-crypto

Thanks for the additional information. I assign the bug to the
partman-crypto package which creates the crypttab entries.

No, with the further information you have supplied the source
of the problem is clear.

Regards,
Karsten