Hi'ya Jonas, On Sun, 27 Jun 2010 11:35:31 +0200 Jonas Meurer <jo...@freesources.org> wrote:
> On 27/06/2010 Clayton wrote: > > On Sat, 26 Jun 2010 12:32:02 +0200 > > Jonas Meurer <jo...@freesources.org> wrote: > > are you sure that this is the case? what does 'blkid /dev/sda' and > 'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no > filesystem should be detected. desktop1:/media# blkid /dev/sdc1 /dev/sdc1: LABEL="HDEXT115" UUID="8dd61b60-2aeb-4b00-a056-a86223d6e47c" TYPE="ext3" desktop1:/media# blkid /dev/sdc2 desktop1:/media# blkid /dev/sda1 /dev/sda1: UUID="9fe8865b-d220-468b-b7a4-bf58b16fe562" TYPE="ext3" desktop1:/media# blkid /dev/sda2 /dev/sda2: UUID="4102f17e-4c54-4ae7-bcfe-00fe90391454" TYPE="swap" So sdc2 is showing no file system, consistent with an encrypted device.... > also you should take a look at /var/log/syslog, and > at /dev/disk/by-id/ in order to find out which device is the > encrypted partition on external USB drive. On my system recently, syslog suddenly contains not much of anything. /var/log/messages contains (this time around): kernel: usb 2-2: New USB device found, idVendor=058f, idProduct=6390 kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb 2-2: Product: USB TO IDE Bridge kernel: usb 2-2: Manufacturer: Generic kernel: usb 2-2: configuration #1 chosen from 1 choice kernel: scsi6 : SCSI emulation for USB Mass Storage devices kernel: scsi 6:0:0:0: Direct-Access Generic USB Disk 9.02 PQ: 0 ANSI: 2 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 kernel: sd 6:0:0:0: [sdc] 320173056 512-byte logical blocks: (163 GB/152 GiB) kernel: sd 6:0:0:0: [sdc] Write Protect is off kernel: sdc: sdc1 sdc2 kernel: sd 6:0:0:0: [sdc] Attached SCSI disk all of which looks fine to me. And # ll /dev/disk/by-id/ total 0 ata-HITACHI_DK23EA-30_N49571 -> ../../sda ata-HITACHI_DK23EA-30_N49571-part1 -> ../../sda1 ata-HITACHI_DK23EA-30_N49571-part2 -> ../../sda2 ata-HITACHI_DK23EA-30_N49571-part3 -> ../../sda3 ata-HITACHI_DK23EA-30_N49571-part4 -> ../../sda4 dm-name-backcrypt -> ../../dm-0 dm-uuid-CRYPT-PLAIN-backcrypt -> ../../dm-0 scsi-SATA_HITACHI_DK23EA-_N49571 -> ../../sda scsi-SATA_HITACHI_DK23EA-_N49571-part1 -> ../../sda1 scsi-SATA_HITACHI_DK23EA-_N49571-part2 -> ../../sda2 scsi-SATA_HITACHI_DK23EA-_N49571-part3 -> ../../sda3 scsi-SATA_HITACHI_DK23EA-_N49571-part4 -> ../../sda4 usb-Generic_USB_Disk-0:0 -> ../../sdc usb-Generic_USB_Disk-0:0-part1 -> ../../sdc1 usb-Generic_USB_Disk-0:0-part2 -> ../../sdc2 which certainly shows crypto going on, though this system has not been rebooted since my last attempt to mount, and those two dm- entries are still there because I never removed the crypto device..... > > So now: cryptsetup create backcrypt /dev/sdb2 > > works. > > this should work for _any_ block device, regardless whether it > contains encrypted fs or not. thus the success of above command does > not indicate that /dev/sdb2 is the correct device. That possibility never occurred to me.... I am now seeing as well that it does not complain about a bad password, either.... > > BUT!!: when I try to mount the partition, this happens: > > > > # mount /media/backcrypt/ > > mount: wrong fs type, bad option, bad superblock on /dev/dm-0, > > missing codepage or helper program, or other error > > In some cases useful info is found in syslog - try > > dmesg | tail or so > > what does 'blkid /dev/mapper/backcrypt' return? # blkid /dev/mapper/backcrypt /dev/mapper/backcrypt: UUID="77f77add-7913-459a-bf81-d88b70323ad6" SEC_TYPE="ext2" TYPE="ext3" and then it gives me the above error message again when I try to mount it..... > the default key size and cipher mode changed for plain dm-crypt in > cryptsetup package 2:1.1.0-1. it seems like you don't > use /etc/crypttab at all, where key size and cipher mode can be > configured. KISS has meant up until now: "don't need crypttab, don't want to mess with it". I am guessing that this may be about to change.... > again, 'cryptsetup create' doesn't fail if either passphrase or > cipher/ hash/keysize are wrong. thus the only way to verify > successfull setup is to check the content of unlocked device. > > try the following (these where the old defaults for cryptsetup before > 1.1.0): > > # cryptsetup --key-size 128 --cipher aes-cbc-plain create > backcrypt /dev/sdb2 > and see what 'blkid /dev/mapper/backcrypt' returns in that case. Well, this is interesting, I too was expecting this to work but it did not: cryptsetup --key-size 128 --cipher aes-cbc-plain create backcrypt /dev/sdc2 mount still fails in the same way, and now # blkid /dev/mapper/backcrypt outputs exactly nothing. If I remove the device and go back to # cryptsetup create backcrypt /dev/sdc2 I then get, again # blkid /dev/mapper/backcrypt /dev/mapper/backcrypt: UUID="77f77add-7913-459a-bf81-d88b70323ad6" SEC_TYPE="ext2" TYPE="ext3" and still a broken mount command. This crypto partition was created several years ago. I wonder if creation defaults have changed more then once since then? But, if the device has not been truly unlocked because of a crypto problem, should blkid be seeing an ext3 file system? Clayton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org