automatic mounting of an encrypted harddrive

[Tobias Schula]

Hi!

I'm using debian sid. I have an encrypted external drive which I use for
backup purposes. When I plug it in it shows up in fdisk, but I have to mount
it manually via cryptsetup and mount. But when using a kubuntu install and
plugging in that drive kde asks me the password of the drive and mounts it
automatically. Do I have to install a specific package or is this behaviour
specific kubunu and impossible in debian?

Tobias


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Moore-8]

On Wednesday October 21 2009 11:26:24 am Tobias Schula wrote:
> I'm using debian sid. I have an encrypted external drive which I use for
> backup purposes. When I plug it in it shows up in fdisk, but I have to
>  mount it manually via cryptsetup and mount. But when using a kubuntu
>  install and plugging in that drive kde asks me the password of the drive
>  and mounts it automatically. Do I have to install a specific package or is
>  this behaviour specific kubunu and impossible in debian?

I am not sure how to get KDE to do this on its own, but you can skip the
cryptsetup step by using mount.crypt from the libpam-mount package.

MM


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[B. Alexander]

I haven't tried it, but take a look at Krypt at http://krypt.berlios.de/.

As for decrypting the drive, I would think if you put the drive into /etc/crypttab, it should remove the need to run the cryptsetup command. I should (hopefully, time permitting) be able to look at this this weekend, as I have an external drive that I intend to encrypt.

--b

On Wed, Oct 21, 2009 at 1:26 PM, Tobias Schula <tobias@...> wrote:

Hi!

I'm using debian sid. I have an encrypted external drive which I use for
backup purposes. When I plug it in it shows up in fdisk, but I have to mount
it manually via cryptsetup and mount. But when using a kubuntu install and
plugging in that drive kde asks me the password of the drive and mounts it
automatically. Do I have to install a specific package or is this behaviour
specific kubunu and impossible in debian?

Tobias


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ritesh]

B. Alexander wrote:

> I haven't tried it, but take a look at Krypt at http://krypt.berlios.de/.
>
> As for decrypting the drive, I would think if you put the drive into
> /etc/crypttab, it should remove the need to run the cryptsetup command. I
> should (hopefully, time permitting) be able to look at this this weekend,
> as I have an external drive that I intend to encrypt.
>

I don't think you need to do that. I too have a cryptsetup LUKS encrypted
drive and what I plug it in, KDE (solid) recognizes it and prompts for the
password to decrypt the drive.

Have a look at the logs, there must be something relevant.

Ritesh
--
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula]

Am Donnerstag 22 Oktober 2009 08:02:48 schrieb Ritesh Raj Sarraf:

> B. Alexander wrote:
> > I haven't tried it, but take a look at Krypt at http://krypt.berlios.de/.
> >
> > As for decrypting the drive, I would think if you put the drive into
> > /etc/crypttab, it should remove the need to run the cryptsetup command. I
> > should (hopefully, time permitting) be able to look at this this weekend,
> > as I have an external drive that I intend to encrypt.
>
> I don't think you need to do that. I too have a cryptsetup LUKS encrypted
> drive and what I plug it in, KDE (solid) recognizes it and prompts for the
> password to decrypt the drive.
>
> Have a look at the logs, there must be something relevant.
>
> Ritesh
>

As you can see in the syslog, the kernel correctly detects the drive. It's
roughly the same output when plugging in a unencrypted drive. So it's kde
related. But whre does kde log its actions?

Tobias



Here's the syslog output when plugging in the encrypted drive:
Oct 22 19:44:36 siduxbox kernel: usb 3-1: new high speed USB device using
ehci_hcd and address 12
Oct 22 19:44:36 siduxbox kernel: usb 3-1: New USB device found, idVendor=1058,
idProduct=1003
Oct 22 19:44:36 siduxbox kernel: usb 3-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Oct 22 19:44:36 siduxbox kernel: usb 3-1: Product: External HDD
Oct 22 19:44:36 siduxbox kernel: usb 3-1: Manufacturer: Western Digital
Oct 22 19:44:36 siduxbox kernel: usb 3-1: SerialNumber:
57442D574D41535936373033363434
Oct 22 19:44:36 siduxbox kernel: usb 3-1: configuration #1 chosen from 1
choice
Oct 22 19:44:36 siduxbox kernel: scsi15 : SCSI emulation for USB Mass Storage
devices
Oct 22 19:44:36 siduxbox kernel: usb-storage: device found at 12
Oct 22 19:44:36 siduxbox kernel: usb-storage: waiting for device to settle
before scanning
Oct 22 19:44:41 siduxbox kernel: usb-storage: device scan complete
Oct 22 19:44:41 siduxbox kernel: scsi 15:0:0:0: Direct-Access     WD      
6400AAK External 1.75 PQ: 0 ANSI: 4
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: Attached scsi generic sg4 type 0
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] 1250263728 512-byte
logical blocks: (640 GB/596 GiB)
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Write Protect is off
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:44:41 siduxbox kernel: sdc: sdc1
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Attached SCSI disk


And here when plugging in an unencrypted drive:
Oct 22 19:47:18 siduxbox kernel: usb 3-1: new high speed USB device using
ehci_hcd and address 13                                                                              
Oct 22 19:47:18 siduxbox kernel: usb 3-1: New USB device found, idVendor=0781,
idProduct=5151                                                                                  
Oct 22 19:47:18 siduxbox kernel: usb 3-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Oct 22 19:47:18 siduxbox kernel: usb 3-1: Product: Cruzer Micro
Oct 22 19:47:18 siduxbox kernel: usb 3-1: Manufacturer: SanDisk
Oct 22 19:47:18 siduxbox kernel: usb 3-1: SerialNumber: 08768018C8416AB5
Oct 22 19:47:18 siduxbox kernel: usb 3-1: configuration #1 chosen from 1
choice
Oct 22 19:47:18 siduxbox kernel: scsi16 : SCSI emulation for USB Mass Storage
devices
Oct 22 19:47:18 siduxbox kernel: usb-storage: device found at 13
Oct 22 19:47:18 siduxbox kernel: usb-storage: waiting for device to settle
before scanning
Oct 22 19:47:23 siduxbox kernel: usb-storage: device scan complete
Oct 22 19:47:23 siduxbox kernel: scsi 16:0:0:0: Direct-Access     SanDisk  
Cruzer           7.01 PQ: 0 ANSI: 0 CCS
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: Attached scsi generic sg4 type 0
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] 15701759 512-byte logical
blocks: (8.03 GB/7.48 GiB)
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Write Protect is off
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Mode Sense: 45 00 00 08
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:47:23 siduxbox kernel: sdc: sdc1
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
write through
Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Attached SCSI removable
disk


At this point kde asks me if I want to mount the drive


Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid 1000


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ritesh]

On Thursday 22 Oct 2009 23:22:03 Tobias Schula wrote:
> At this point kde asks me if I want to mount the drive
>
>
> Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid 1000
>

So is hald running under Debian ?

Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[B. Alexander]

So it sees the drive. Is it listed in /etc/crypttab? That is what
should cause it to prompt you for the passphrase.

On 10/22/09, Tobias Schula <tobias@...> wrote:

> Am Donnerstag 22 Oktober 2009 08:02:48 schrieb Ritesh Raj Sarraf:
>> B. Alexander wrote:
>> > I haven't tried it, but take a look at Krypt at
>> > http://krypt.berlios.de/.
>> >
>> > As for decrypting the drive, I would think if you put the drive into
>> > /etc/crypttab, it should remove the need to run the cryptsetup command.
>> > I
>> > should (hopefully, time permitting) be able to look at this this
>> > weekend,
>> > as I have an external drive that I intend to encrypt.
>>
>> I don't think you need to do that. I too have a cryptsetup LUKS encrypted
>> drive and what I plug it in, KDE (solid) recognizes it and prompts for the
>> password to decrypt the drive.
>>
>> Have a look at the logs, there must be something relevant.
>>
>> Ritesh
>>
>
> As you can see in the syslog, the kernel correctly detects the drive. It's
> roughly the same output when plugging in a unencrypted drive. So it's kde
> related. But whre does kde log its actions?
>
> Tobias
>
>
>
> Here's the syslog output when plugging in the encrypted drive:
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: new high speed USB device using
> ehci_hcd and address 12
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: New USB device found,
> idVendor=1058,
> idProduct=1003
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: Product: External HDD
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: Manufacturer: Western Digital
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: SerialNumber:
> 57442D574D41535936373033363434
> Oct 22 19:44:36 siduxbox kernel: usb 3-1: configuration #1 chosen from 1
> choice
> Oct 22 19:44:36 siduxbox kernel: scsi15 : SCSI emulation for USB Mass
> Storage
> devices
> Oct 22 19:44:36 siduxbox kernel: usb-storage: device found at 12
> Oct 22 19:44:36 siduxbox kernel: usb-storage: waiting for device to settle
> before scanning
> Oct 22 19:44:41 siduxbox kernel: usb-storage: device scan complete
> Oct 22 19:44:41 siduxbox kernel: scsi 15:0:0:0: Direct-Access     WD
> 6400AAK External 1.75 PQ: 0 ANSI: 4
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: Attached scsi generic sg4 type
> 0
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] 1250263728 512-byte
> logical blocks: (640 GB/596 GiB)
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Write Protect is off
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Mode Sense: 23 00 00 00
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:44:41 siduxbox kernel: sdc: sdc1
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:44:41 siduxbox kernel: sd 15:0:0:0: [sdc] Attached SCSI disk
>
>
> And here when plugging in an unencrypted drive:
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: new high speed USB device using
> ehci_hcd and address 13
>
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: New USB device found,
> idVendor=0781,
> idProduct=5151
>
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: Product: Cruzer Micro
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: Manufacturer: SanDisk
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: SerialNumber: 08768018C8416AB5
> Oct 22 19:47:18 siduxbox kernel: usb 3-1: configuration #1 chosen from 1
> choice
> Oct 22 19:47:18 siduxbox kernel: scsi16 : SCSI emulation for USB Mass
> Storage
> devices
> Oct 22 19:47:18 siduxbox kernel: usb-storage: device found at 13
> Oct 22 19:47:18 siduxbox kernel: usb-storage: waiting for device to settle
> before scanning
> Oct 22 19:47:23 siduxbox kernel: usb-storage: device scan complete
> Oct 22 19:47:23 siduxbox kernel: scsi 16:0:0:0: Direct-Access     SanDisk
> Cruzer           7.01 PQ: 0 ANSI: 0 CCS
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: Attached scsi generic sg4 type
> 0
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] 15701759 512-byte
> logical
> blocks: (8.03 GB/7.48 GiB)
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Write Protect is off
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Mode Sense: 45 00 00 08
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:47:23 siduxbox kernel: sdc: sdc1
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Assuming drive cache:
> write through
> Oct 22 19:47:23 siduxbox kernel: sd 16:0:0:0: [sdc] Attached SCSI removable
> disk
>
>
> At this point kde asks me if I want to mount the drive
>
>
> Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid 1000
>
>
> --
> To UNSUBSCRIBE, email to debian-kde-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ritesh]

On Friday 23 Oct 2009 00:04:52 B. Alexander wrote:
> So it sees the drive. Is it listed in /etc/crypttab? That is what
> should cause it to prompt you for the passphrase.
>

I don't think you need an entry in /etc/crypttab.
My crypttab is empty. It is hal that detects the encrypted device and
accordingly acts on it.

Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[Tobias Schula]

Am Donnerstag 22 Oktober 2009 20:25:15 schrieb Ritesh Raj Sarraf:

> On Thursday 22 Oct 2009 23:22:03 Tobias Schula wrote:
> > At this point kde asks me if I want to mount the drive
> >
> >
> > Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid 1000
>
> So is hald running under Debian ?
>
> Ritesh
>

Yes, hald is running.


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sat, Oct 24, 2009 at 21:01:03 +0200, Tobias Schula wrote:

> Am Donnerstag 22 Oktober 2009 20:25:15 schrieb Ritesh Raj Sarraf:
> > On Thursday 22 Oct 2009 23:22:03 Tobias Schula wrote:
> > > At this point kde asks me if I want to mount the drive
> > >
> > >
> > > Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid 1000
> >
> > So is hald running under Debian ?
> >
> > Ritesh
> >
>
> Yes, hald is running.

I would be interested in the output of this command (after the encrypted
USB stick has been plugged in for at least 30 seconds):

lshal -u $(hal-find-by-property --key volume.fsusage --string crypto)

--
Regards,            | http://users.icfo.es/Florian.Kulzer
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula]

Am Samstag 24 Oktober 2009 22:16:00 schrieb Florian Kulzer:

> On Sat, Oct 24, 2009 at 21:01:03 +0200, Tobias Schula wrote:
> > Am Donnerstag 22 Oktober 2009 20:25:15 schrieb Ritesh Raj Sarraf:
> > > On Thursday 22 Oct 2009 23:22:03 Tobias Schula wrote:
> > > > At this point kde asks me if I want to mount the drive
> > > >
> > > >
> > > > Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid
> > > > 1000
> > >
> > > So is hald running under Debian ?
> > >
> > > Ritesh
> >
> > Yes, hald is running.
>
> I would be interested in the output of this command (after the encrypted
> USB stick has been plugged in for at least 30 seconds):
>
> lshal -u $(hal-find-by-property --key volume.fsusage --string crypto)
>

No luck with that:

root@siduxbox:~# lshal -u $(hal-find-by-property --key volume.fsusage --string
crypto)
lshal: option requires an argument -- 'u'
lshal version 0.5.13

usage : lshal [options]

<snip />




--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sun, Oct 25, 2009 at 00:47:38 +0200, Tobias Schula wrote:

> Am Samstag 24 Oktober 2009 22:16:00 schrieb Florian Kulzer:
> > On Sat, Oct 24, 2009 at 21:01:03 +0200, Tobias Schula wrote:
> > > Am Donnerstag 22 Oktober 2009 20:25:15 schrieb Ritesh Raj Sarraf:
> > > > On Thursday 22 Oct 2009 23:22:03 Tobias Schula wrote:
> > > > > At this point kde asks me if I want to mount the drive
> > > > >
> > > > >
> > > > > Oct 22 19:47:34 siduxbox hald: mounted /dev/sdc1 on behalf of uid
> > > > > 1000
> > > >
> > > > So is hald running under Debian ?

[...]

> > > Yes, hald is running.
> >
> > I would be interested in the output of this command (after the encrypted
> > USB stick has been plugged in for at least 30 seconds):
> >
> > lshal -u $(hal-find-by-property --key volume.fsusage --string crypto)
> >
>
> No luck with that:
>
> root@siduxbox:~# lshal -u $(hal-find-by-property --key volume.fsusage --string
> crypto)
> lshal: option requires an argument -- 'u'

That probably means that HAL does not set the crypto-related properties
for the device, which would explain why KDE does not know how to handle
it.

Let's try this instead:

lshal -u $(hal-find-by-property --key block.device --string '/dev/sda1')

(replace '/dev/sda1' with the correct device node for your USB stick)

--
Regards,            | http://users.icfo.es/Florian.Kulzer
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula-2]

Am Sonntag 25 Oktober 2009 10:28:34 schrieb Florian Kulzer:

> On Sun, Oct 25, 2009 at 00:47:38 +0200, Tobias Schula wrote:
> > Am Samstag 24 Oktober 2009 22:16:00 schrieb Florian Kulzer:
> > > On Sat, Oct 24, 2009 at 21:01:03 +0200, Tobias Schula wrote:
>
> [...]
>
> > > > Yes, hald is running.
> > >
> > > I would be interested in the output of this command (after the
> > > encrypted USB stick has been plugged in for at least 30 seconds):
> > >
> > > lshal -u $(hal-find-by-property --key volume.fsusage --string crypto)
> >
> > No luck with that:
> >
> > root@siduxbox:~# lshal -u $(hal-find-by-property --key volume.fsusage
> > --string crypto)
> > lshal: option requires an argument -- 'u'
>
> That probably means that HAL does not set the crypto-related properties
> for the device, which would explain why KDE does not know how to handle
> it.
>
> Let's try this instead:
>
> lshal -u $(hal-find-by-property --key block.device --string '/dev/sda1')
>
> (replace '/dev/sda1' with the correct device node for your USB stick)
>

root@siduxbox:~# lshal -u $(hal-find-by-property --key block.device --string
'/dev/sdc1')
udi = '/org/freedesktop/Hal/devices/volume_part1_size_640132383744'                                
  block.device = '/dev/sdc1'  (string)                                                              
  block.is_volume = true  (bool)                                                                    
  block.major = 8  (0x8)  (int)                                                                    
  block.minor = 33  (0x21)  (int)                                                                  
  block.storage_device =
'/org/freedesktop/Hal/devices/storage_serial_WD_6400AAK_External_57442D574D41535936373033363434_0_0'  
(string)
  info.capabilities = {'volume', 'block'} (string list)
  info.category = 'volume'  (string)
  info.parent =
'/org/freedesktop/Hal/devices/storage_serial_WD_6400AAK_External_57442D574D41535936373033363434_0_0'  
(string)
  info.product = 'Volume'  (string)
  info.udi = '/org/freedesktop/Hal/devices/volume_part1_size_640132383744'  
(string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path =
'/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc/sdc1'  
(string)
  volume.block_size = 512  (0x200)  (int)
  volume.fstype = ''  (string)
  volume.fsusage = ''  (string)
  volume.fsversion = ''  (string)
  volume.is_disc = false  (bool)
  volume.is_mounted = false  (bool)
  volume.is_mounted_read_only = false  (bool)
  volume.is_partition = true  (bool)
  volume.label = ''  (string)
  volume.linux.is_device_mapper = false  (bool)
  volume.mount_point = ''  (string)
  volume.num_blocks = 1250258562  (0x4a856e82)  (uint64)
  volume.partition.flags = {} (string list)
  volume.partition.label = ''  (string)
  volume.partition.media_size = 640135028736  (0x950b056000)  (uint64)
  volume.partition.number = 1  (0x1)  (int)
  volume.partition.scheme = 'mbr'  (string)
  volume.partition.start = 32256  (0x7e00)  (uint64)
  volume.partition.type = '0x83'  (string)
  volume.partition.uuid = ''  (string)
  volume.size = 640132383744  (0x950add0400)  (uint64)
  volume.uuid = ''  (string)


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Fri, Nov 06, 2009 at 16:37:11 +0100, Tobias Schula wrote:
> Am Sonntag 25 Oktober 2009 10:28:34 schrieb Florian Kulzer:

[...]

> > That probably means that HAL does not set the crypto-related properties
> > for the device, which would explain why KDE does not know how to handle
> > it.

[...]

> root@siduxbox:~# lshal -u $(hal-find-by-property --key block.device --string '/dev/sdc1')
> udi = '/org/freedesktop/Hal/devices/volume_part1_size_640132383744'                                
>   block.device = '/dev/sdc1'  (string)                                                              
>   block.is_volume = true  (bool)                                                                    
>   block.major = 8  (0x8)  (int)                                                                    
>   block.minor = 33  (0x21)  (int)                                                                  
>   block.storage_device =
> '/org/freedesktop/Hal/devices/storage_serial_WD_6400AAK_External_57442D574D41535936373033363434_0_0'  (string)
>   info.capabilities = {'volume', 'block'} (string list)
>   info.category = 'volume'  (string)

An important property is missing here:

  info.interfaces = {'org.freedesktop.Hal.Device.Volume.Crypto'} (string list)

[...]

>   volume.fstype = ''  (string)
>   volume.fsusage = ''  (string)
>   volume.fsversion = ''  (string)

These three lines should look like this:

  volume.fstype = 'crypto_LUKS'  (string)
  volume.fsusage = 'crypto'  (string)
  volume.fsversion = '256'  (string)

Udev should set these properties based on the results of running
/sbin/blkid on the device, triggered by 60-persistent-storage.rules. We
have to find out why this does not happen on your system.

Please run

  udevadm test $(udevadm info --query=path -n /dev/sdc1)

, make the output available on http://debian.pastebin.com (or a similar
site of your choice) and post the link here.

--
Regards,            |
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula]

Am Freitag 06 November 2009 23:21:57 schrieb Florian Kulzer:

> On Fri, Nov 06, 2009 at 16:37:11 +0100, Tobias Schula wrote:
> > Am Sonntag 25 Oktober 2009 10:28:34 schrieb Florian Kulzer:
>
> [...]
>
> > > That probably means that HAL does not set the crypto-related properties
> > > for the device, which would explain why KDE does not know how to handle
> > > it.
>
> [...]
>
> > root@siduxbox:~# lshal -u $(hal-find-by-property --key block.device
> > --string '/dev/sdc1') udi =
> > '/org/freedesktop/Hal/devices/volume_part1_size_640132383744'
> > block.device = '/dev/sdc1'  (string)
> >   block.is_volume = true  (bool)
> >   block.major = 8  (0x8)  (int)
> >   block.minor = 33  (0x21)  (int)
> >   block.storage_device =
> > '/org/freedesktop/Hal/devices/storage_serial_WD_6400AAK_External_57442D57
> >4D41535936373033363434_0_0'  (string) info.capabilities = {'volume',
> > 'block'} (string list)
> >   info.category = 'volume'  (string)
>
> An important property is missing here:
>
>   info.interfaces = {'org.freedesktop.Hal.Device.Volume.Crypto'} (string
>  list)
>
> [...]
>
> >   volume.fstype = ''  (string)
> >   volume.fsusage = ''  (string)
> >   volume.fsversion = ''  (string)
>
> These three lines should look like this:
>
>   volume.fstype = 'crypto_LUKS'  (string)
>   volume.fsusage = 'crypto'  (string)
>   volume.fsversion = '256'  (string)
>
> Udev should set these properties based on the results of running
> /sbin/blkid on the device, triggered by 60-persistent-storage.rules. We
> have to find out why this does not happen on your system.
>
> Please run
>
>   udevadm test $(udevadm info --query=path -n /dev/sdc1)
>
> , make the output available on http://debian.pastebin.com (or a similar
> site of your choice) and post the link here.
>

OK, here's the output: http://debian.pastebin.com/m2a365e1f


Regards

Tobias


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sat, Nov 07, 2009 at 15:54:17 +0100, Tobias Schula wrote:
> Am Freitag 06 November 2009 23:21:57 schrieb Florian Kulzer:
> > On Fri, Nov 06, 2009 at 16:37:11 +0100, Tobias Schula wrote:
> > > Am Sonntag 25 Oktober 2009 10:28:34 schrieb Florian Kulzer:
> >
> > [...]
> >
> > > > That probably means that HAL does not set the crypto-related properties
> > > > for the device, which would explain why KDE does not know how to handle
> > > > it.

[...]

> > These three lines should look like this:
> >
> >   volume.fstype = 'crypto_LUKS'  (string)
> >   volume.fsusage = 'crypto'  (string)
> >   volume.fsversion = '256'  (string)
> >
> > Udev should set these properties based on the results of running
> > /sbin/blkid on the device, triggered by 60-persistent-storage.rules. We
> > have to find out why this does not happen on your system.
> >
> > Please run
> >
> >   udevadm test $(udevadm info --query=path -n /dev/sdc1)

[...]

> OK, here's the output: http://debian.pastebin.com/m2a365e1f

Here is your problem:

  udev_rules_apply_to_event: IMPORT '/sbin/blkid -o udev -p /dev/sdc1' /lib/udev/rules.d/60-persistent-storage.rules:129
  util_run_program: '/sbin/blkid -o udev -p /dev/sdc1' started
  util_run_program: '/sbin/blkid' (stderr) '/dev/sdc1: ambivalent result (probably more filesystems on the device)'
  util_run_program: '/sbin/blkid -o udev -p /dev/sdc1' returned with exitcode 2

Blkid cannot identify the filesystem on sdc1. It should work like this
(my encrypted USB stick is /dev/sda1):

  $ /sbin/blkid -p /dev/sda1
  /dev/sda1: UUID="60160a54-2d59-46f7-b46f-3490a767e820" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"

Make sure you have the up-to-date versions of these packages:

  $ dpkg -l util-linux libblkid1 libuuid1 | awk '/^ii/{print $2,$3}'
  libblkid1 2.16.1-4
  libuuid1 2.16.1-4
  util-linux 2.16.1-4

Also, are you sure that you have a standard crypto_LUKS partition? How
did you set it up?

--
Regards,            |
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula]

Am Samstag 07 November 2009 17:20:44 schrieb Florian Kulzer:

> On Sat, Nov 07, 2009 at 15:54:17 +0100, Tobias Schula wrote:
> > Am Freitag 06 November 2009 23:21:57 schrieb Florian Kulzer:
> > > On Fri, Nov 06, 2009 at 16:37:11 +0100, Tobias Schula wrote:
> > > > Am Sonntag 25 Oktober 2009 10:28:34 schrieb Florian Kulzer:
> > >
> > > [...]
> > >
> > > > > That probably means that HAL does not set the crypto-related
> > > > > properties for the device, which would explain why KDE does not
> > > > > know how to handle it.
>
> [...]
>
> > > These three lines should look like this:
> > >
> > >   volume.fstype = 'crypto_LUKS'  (string)
> > >   volume.fsusage = 'crypto'  (string)
> > >   volume.fsversion = '256'  (string)
> > >
> > > Udev should set these properties based on the results of running
> > > /sbin/blkid on the device, triggered by 60-persistent-storage.rules. We
> > > have to find out why this does not happen on your system.
> > >
> > > Please run
> > >
> > >   udevadm test $(udevadm info --query=path -n /dev/sdc1)
>
> [...]
>
> > OK, here's the output: http://debian.pastebin.com/m2a365e1f
>
> Here is your problem:
>
>   udev_rules_apply_to_event: IMPORT '/sbin/blkid -o udev -p /dev/sdc1'
>  /lib/udev/rules.d/60-persistent-storage.rules:129 util_run_program:
>  '/sbin/blkid -o udev -p /dev/sdc1' started
>   util_run_program: '/sbin/blkid' (stderr) '/dev/sdc1: ambivalent result
>  (probably more filesystems on the device)' util_run_program: '/sbin/blkid
>  -o udev -p /dev/sdc1' returned with exitcode 2
>
> Blkid cannot identify the filesystem on sdc1. It should work like this
> (my encrypted USB stick is /dev/sda1):
>
>   $ /sbin/blkid -p /dev/sda1
>   /dev/sda1: UUID="60160a54-2d59-46f7-b46f-3490a767e820" VERSION="256"
>  TYPE="crypto_LUKS" USAGE="crypto"

Ah, I see, this is the output on my computer:
        # /sbin/blkid -p /dev/sdc1
        /dev/sdc1: ambivalent result (probably more filesystems on the device)


>
> Make sure you have the up-to-date versions of these packages:
>
>   $ dpkg -l util-linux libblkid1 libuuid1 | awk '/^ii/{print $2,$3}'
>   libblkid1 2.16.1-4
>   libuuid1 2.16.1-4
>   util-linux 2.16.1-4

All up to date:
        # dpkg -l util-linux libblkid1 libuuid1 | awk '/^ii/{print $2,$3}'
        libblkid1 2.16.1-4
        libuuid1 2.16.1-4
        util-linux 2.16.1-4

>
> Also, are you sure that you have a standard crypto_LUKS partition? How
> did you set it up?
>

I erased all data it previously contained:
# dd if=/dev/urandom of=/dev/sdc1

I set up the crypt device:
# cryptsetup luksFormat /dev/sdc1

Opening the device mapper:
# cryptsetup luksOpen /dev/sdc1 crypt_backup

Formating it with ext3:
# mkfs.ext3 /dev/mapper/crypt_backup

Mounting the file system:
# mount /dev/mapper/crypt_backup /mnt

Setting rights:
# chown 1000:1000 /mnt

Unmounting the file system:
# umount /dev/mapper/crypt_backup

Closing device mapper:
# cryptsetup luksClose crypt_backup

After these steps I was able to plug it in and the KDE device notifier showed
me the new drive. But I didn't set it up in Debian but in Kubuntu if that's
important.


Regards

Tobias


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sun, Nov 08, 2009 at 13:01:36 +0100, Tobias Schula wrote:
> Am Samstag 07 November 2009 17:20:44 schrieb Florian Kulzer:

[...]

> > Blkid cannot identify the filesystem on sdc1. It should work like this
> > (my encrypted USB stick is /dev/sda1):
> >
> >   $ /sbin/blkid -p /dev/sda1
> >   /dev/sda1: UUID="60160a54-2d59-46f7-b46f-3490a767e820" VERSION="256"
> >  TYPE="crypto_LUKS" USAGE="crypto"
>
> Ah, I see, this is the output on my computer:
> # /sbin/blkid -p /dev/sdc1
> /dev/sdc1: ambivalent result (probably more filesystems on the device)

[ snip: util-linux, libblkid1 and libuuid1 are all up-to-date ]

> > Also, are you sure that you have a standard crypto_LUKS partition? How
> > did you set it up?
>
> I erased all data it previously contained:
> # dd if=/dev/urandom of=/dev/sdc1
>
> I set up the crypt device:
> # cryptsetup luksFormat /dev/sdc1
>
> Opening the device mapper:
> # cryptsetup luksOpen /dev/sdc1 crypt_backup
>
> Formating it with ext3:
> # mkfs.ext3 /dev/mapper/crypt_backup
>
> Mounting the file system:
> # mount /dev/mapper/crypt_backup /mnt
>
> Setting rights:
> # chown 1000:1000 /mnt
>
> Unmounting the file system:
> # umount /dev/mapper/crypt_backup
>
> Closing device mapper:
> # cryptsetup luksClose crypt_backup
>
> After these steps I was able to plug it in and the KDE device notifier showed
> me the new drive. But I didn't set it up in Debian but in Kubuntu if that's
> important.

I cannot find anything wrong with your procedure. I think the fact that
you used Kubunutu should not matter.

Please show me the partition table of the disk/stick and the beginning
of the LUKS partition, i.e. the output of:

  fdisk -l /dev/sdc
 
  hd -n 80 /dev/sdc1

--
Regards,            |
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tobias Schula]

Am Sonntag 08 November 2009 14:34:45 schrieb Florian Kulzer:

> On Sun, Nov 08, 2009 at 13:01:36 +0100, Tobias Schula wrote:
> > Am Samstag 07 November 2009 17:20:44 schrieb Florian Kulzer:
>
> [...]
>
> > > Blkid cannot identify the filesystem on sdc1. It should work like this
> > > (my encrypted USB stick is /dev/sda1):
> > >
> > >   $ /sbin/blkid -p /dev/sda1
> > >   /dev/sda1: UUID="60160a54-2d59-46f7-b46f-3490a767e820" VERSION="256"
> > >  TYPE="crypto_LUKS" USAGE="crypto"
> >
> > Ah, I see, this is the output on my computer:
> > # /sbin/blkid -p /dev/sdc1
> > /dev/sdc1: ambivalent result (probably more filesystems on the device)
>
> [ snip: util-linux, libblkid1 and libuuid1 are all up-to-date ]
>
> > > Also, are you sure that you have a standard crypto_LUKS partition? How
> > > did you set it up?

[…]

> >
> > After these steps I was able to plug it in and the KDE device notifier
> > showed me the new drive. But I didn't set it up in Debian but in Kubuntu
> > if that's important.
>
> I cannot find anything wrong with your procedure. I think the fact that
> you used Kubunutu should not matter.
>
> Please show me the partition table of the disk/stick and the beginning
> of the LUKS partition, i.e. the output of:
>
>   fdisk -l /dev/sdc

        # fdisk -l /dev/sdc
       
        Disk /dev/sdc: 640.1 GB, 640135028736 bytes
        255 heads, 63 sectors/track, 77825 cylinders
        Units = cylinders of 16065 * 512 = 8225280 bytes
        Disk identifier: 0x257dbcd5

           Device Boot      Start         End      Blocks   Id  System
        /dev/sdc1               1       77825   625129281   83  Linux


>   hd -n 80 /dev/sdc1

# hd -n 80 /dev/sdc1
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|
00000030  6e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |n...............|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
00000050
 

Here's one strange thing: I encrypted USB flash drive following the steps
above. But this time it works! What's the difference between the two?
The following output is from my flash drive:

        # fdisk -l /dev/sdc
       
        Disk /dev/sdc: 8039 MB, 8039300608 bytes
        255 heads, 63 sectors/track, 977 cylinders
        Units = cylinders of 16065 * 512 = 8225280 bytes
        Disk identifier: 0xe8070000
       
           Device Boot      Start         End      Blocks   Id  System
        /dev/sdc1               1         977     7847721    b  W95 FAT32


# hd -n 80 /dev/sdc1
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
00000050

It seems that Ubuntu uses xts-plain but Sid cbc-essiv and the SHA-256
algorithm. But it's strange that both drives are recognised by Kubuntu but
only the flash drive by Debian.


Regards

Tobias


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sun, Nov 08, 2009 at 21:48:05 +0100, Tobias Schula wrote:
> Am Sonntag 08 November 2009 14:34:45 schrieb Florian Kulzer:
> > On Sun, Nov 08, 2009 at 13:01:36 +0100, Tobias Schula wrote:

[...]

> > > Ah, I see, this is the output on my computer:
> > > # /sbin/blkid -p /dev/sdc1
> > > /dev/sdc1: ambivalent result (probably more filesystems on the device)

[...]

> > > After these steps I was able to plug it in and the KDE device notifier
> > > showed me the new drive. But I didn't set it up in Debian but in Kubuntu
> > > if that's important.
> >
> > I cannot find anything wrong with your procedure. I think the fact that
> > you used Kubunutu should not matter.

Denken ist Glückssache...

[...]

> # hd -n 80 /dev/sdc1
> 00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|
> 00000030  6e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |n...............|
> 00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
> 00000050
>  
>
> Here's one strange thing: I encrypted USB flash drive following the steps
> above. But this time it works! What's the difference between the two?

[...]

> # hd -n 80 /dev/sdc1
> 00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
> 00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
> 00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
> 00000050
>
> It seems that Ubuntu uses xts-plain but Sid cbc-essiv and the SHA-256
> algorithm. But it's strange that both drives are recognised by Kubuntu but
> only the flash drive by Debian.

It looks like blkid has a bug that has been fixed in Ubuntu, see their
changelog of util-linux:

util-linux (2.16-1ubuntu5) karmic; urgency=low

  * Always return encrypted block devices as the first detected encryption
    system (ie. LUKS, since that's the only one) rather than probing for
    additional metadata and returning an ambivalent result.  LP: #428435.

 -- Scott James Remnant <scott AT ubuntu DOT com>  Wed, 21 Oct 2009 14:22:31 +0100

You can file a bug report against Debian's util-linux and ask the
maintainer to take over the Ubuntu fix.

--
Regards,            |
          Florian   |


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...