Closed GoogleCodeExporter closed 9 years ago
Yes, you are right that all status information a in DM device table.
But it was intentional limitation here - we need LUKS header to properly
initialize context to CRYPT_LUKS1. What should happen e.g. when you will later
query key slots?
So LUKS device without header appears like "unknown" device, basically allowing
only crypt_deactivate().
But I agree status should print some more info... Not a priority but will think
how to fix that.
Thanks.
Original comment by gmazyl...@gmail.com
on 27 Mar 2014 at 6:52
Added some support for status for "unknown" crypt device
https://code.google.com/p/cryptsetup/source/detail?r=0614ab6b070b3af44bb7aabf4c2
fedc3d1fe1e0c
The type is not available (n/a) but cipher and key size option can be used.
Original comment by gmazyl...@gmail.com
on 14 Jun 2014 at 3:46
It now returns values but most of them are missing.This is what i am seeing
here:
[root@mtz cryptsetup]# /usr/sbin/cryptsetup status
/dev/mapper/zuluCrypt-500-NAAN-header-image-file.img-3107929503
/dev/mapper/zuluCrypt-500-NAAN-header-image-file.img-3107929503 is active and
is in use.
type: n/a
cipher: (null)-(null)
keysize: 0 bits
device: /dev/loop0
loop: /home/ink/zc/header-image-file.img
offset: 0 sectors
size: 40000 sectors
mode: readonly
[root@mtz cryptsetup]#
Original comment by mhogomch...@gmail.com
on 14 Jun 2014 at 5:09
Are you sure you are using correct libcryptsetup with changes? It seems like
only cryptsetup binary change is applied here.
# src/cryptsetup status x
/dev/mapper/x is active.
type: n/a
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/sdb
offset: 0 sectors
size: 417792 sectors
mode: read/write
Original comment by gmazyl...@gmail.com
on 14 Jun 2014 at 5:18
yes,the old libcryptsetup would have failed as i reported in my initial bug
report.
The old libcryptsetup would also not have reported "n/a" as type as my latest
report indicated.
Have you tried the test on an image file?
Original comment by mhogomch...@gmail.com
on 14 Jun 2014 at 6:00
Nope, check which libcryptsetup you are using - you have probably compiled new
one but cryptsetup uses system installed version.
(I will increase version in release but not now.)
See - this is with wrapper (so devel library is used)
# src/cryptsetup status x
/dev/mapper/x is active.
type: n/a
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/loop1
loop: /img.tst
offset: 0 sectors
size: 65536 sectors
mode: readonly
And this is how it looks like when it uses old library
# src/.libs/cryptsetup status x
/dev/mapper/x is active.
type: n/a
cipher: (null)-(null)
keysize: 0 bits
device: /dev/loop1
loop: /img.tst
offset: 0 sectors
size: 65536 sectors
mode: readonly
# ldd src/.libs/cryptsetup |grep libcryptsetup
libcryptsetup.so.4 => /usr/lib/libcryptsetup.so.4 (0xb772d000)
Original comment by gmazyl...@gmail.com
on 14 Jun 2014 at 7:50
I only one libcryptsetup installed and its from the latest git version.
It seems like you are getting the results you are getting because the mapper is
not in use,put a file system on it and then mount it and you will get the
output i am getting.Here is an example
[root@mtz cryptsetup]# cryptsetup status /dev/mapper/rrr
/dev/mapper/rrr is active and is in use.
type: n/a
cipher: (null)-(null)
keysize: 0 bits
device: /dev/mapper/lvm-p
offset: 0 sectors
size: 40960 sectors
mode: read/write
[root@mtz cryptsetup]# umount /dev/mapper/rrr
[root@mtz cryptsetup]# cryptsetup status /dev/mapper/rrr
/dev/mapper/rrr is active.
type: n/a
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/mapper/lvm-p
offset: 0 sectors
size: 40960 sectors
mode: read/write
[root@mtz cryptsetup]#
Original comment by mhogomch...@gmail.com
on 14 Jun 2014 at 8:33
Ah, you are right. This was stupid cleanup mistake before commit.
Try it now.
Thanks.
Original comment by gmazyl...@gmail.com
on 14 Jun 2014 at 9:09
It now works as expected.
crypt_get_type() still return NULL though.Is this expected return value?
It seems contradicting for the binary to return "n/a" while the API returns
NULL.
Original comment by mhogomch...@gmail.com
on 14 Jun 2014 at 9:33
Yes, type is NULL (as it was previously).
"NULL" or empty string is not much user friendly, so that's why "type not
available".
I can replace it with something better but have no better idea :)
(But really not NULL, this is more programmer's jargon.)
Original comment by gmazyl...@gmail.com
on 14 Jun 2014 at 9:53
Original issue reported on code.google.com by
mhogomch...@gmail.com
on 26 Mar 2014 at 3:37