Hi Karsten:
Am 27.03.2015 um 15:57 schrieb Karsten Merker:
> Could you provide further information that would enable us to
> reproduce the problem?
Yes. Sry for having submitted this in a hurry without having taken a
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.
> In particular the install-time logfiles
> (available under /var/log/installer) and the contents of
> /etc/fstab and /etc/crypttab as well as the output of "ls -l
> /dev/mapper" and "fdisk -l" on the installed system would be
> helpful.
Do you still need any of that? I'd reproduce IOT help troubleshoot.
> Could you also provide the exact URL of the installer image that
> you have used?
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
--
Kevin Price
http://www.kevin-price.de/
Attachment:
signature.asc
Description: OpenPGP digital signature