All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] LUKS1 devmapper device mount issue
@ 2016-04-08 20:46 Amith Kumar Ramachandra
  2016-04-09 12:36 ` Michael Kjörling
  2016-04-10  5:15 ` Amith Kumar Ramachandra
  0 siblings, 2 replies; 6+ messages in thread
From: Amith Kumar Ramachandra @ 2016-04-08 20:46 UTC (permalink / raw)
  To: dm-crypt


[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]

Hi!

 I am working on an armv8 embedded platform running 3.18 linux kernel. I am
setting up disk encryption on a peripheral MMC card using cryptsetup-1.6.3
version.

I am able to get through the first couple of steps of cryptsetup
(luksFormat and luksOpen) without any issue. Commands here below:

cryptsetup -v -y -c "aes-cbc-essiv:sha256" luksFormat /dev/mmcblk1p1
--batch-mode --debug
cryptsetup luksOpen /dev/mmcblk1p1 data --debug

I can see the device /dev/mapper/data getting created as expected. I dumped
its status and it looks fine from what I can see:

root@p2382_t186:~# dmsetup info /dev/mapper/data
Name:              data
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      254, 1
Number of targets: 1
UUID: CRYPT-LUKS1-ff6bc36961ab46948c702456fa8b722b-data

But when I format the device as ext4 and mount it at /mnt, I don't see the
device mounted. The mount command itself did not fail. It gives me success
(verified both from the return status and kernel dmesg logs) but the LUKS1
device is not getting mounted.

However, when I create a crypt device using dmsetup, I am able to see and
mount the volume1 device as expected.

echo 0 `blockdev --getsize /dev/mmcblk1p1` crypt aes-cbc-essiv:sha256
0123456789abcdef0123456789abcdef 0 /dev/mmcblk1p1 0 | dmsetup create volume1

I have attached the debug logs if you are interested.

Could you pls let me know what I might be missing?

Appreciate your help!
Thanks,
Amith

[-- Attachment #1.2: Type: text/html, Size: 1997 bytes --]

[-- Attachment #2: luks-mount-issue.txt --]
[-- Type: text/plain, Size: 10589 bytes --]


cryptsetup -v -y -c "aes-cbc-essiv:sha256" luksFormat /dev/mmcblk1p1 --batch-mode --debug
# cryptsetup 1.6.3 processing "cryptsetup -v -y -c aes-cbc-essiv:sha256 luksFormat /dev/mmcblk1p1 --batch-mode --debug"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/mmcblk1p1 context.
# Trying to open and read device /dev/mmcblk1p1.
# Initialising device-mapper backend library.
# Timeout set to 0 miliseconds.
# Iteration time set to 1000 miliseconds.
# Interactive passphrase entry requested.
Enter passphrase:
Verify passphrase:
p1 as type LUKS1.
# Crypto backend (gcrypt 1.6.2) initialized.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Checking if cipher aes-cbc-essiv:sha256 is usable.
# Calculated device size is 1 sectors (RW), offset 0.
# Detected kernel Linux 3.18.21-tegra aarch64.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.28.0.
# Device-mapper backend running with UDEV support disabled.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-3214
# dm create temporary-cryptsetup-3214 CRYPT-TEMP-temporary-cryptsetup-3214 OF   [16384] (*1)
# dm reload temporary-cryptsetup-3214  OFRW    [16384] (*1)
# Cookie value is not set while trying to call DM_DEVICE_RESUME ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm resume temporary-cryptsetup-3214  OFRW    [16384] (*1)
# temporary-cryptsetup-3214: Stacking NODE_ADD (254,1) 0:6 0660
# temporary-cryptsetup-3214: Stacking NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3214: Processing NODE_ADD (254,1) 0:6 0660
# Created /dev/mapper/temporary-cryptsetup-3214
# temporary-cryptsetup-3214: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3214 (254:1): read ahead is 256
# temporary-cryptsetup-3214: retaining kernel read ahead of 256 (requested 256)
# Cookie value is not set while trying to call DM_DEVICE_REMOVE ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm remove temporary-cryptsetup-3214  OFT    [16384] (*1)
# temporary-cryptsetup-3214: Stacking NODE_DEL
# temporary-cryptsetup-3214: Processing NODE_DEL
# Removed /dev/mapper/temporary-cryptsetup-3214
# Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK 32 bytes
# Crypto backend (gcrypt 1.6.2) initialized.
# KDF pbkdf2, hash sha1: 1048576 iterations per second.
# Data offset 4096, UUID ff6bc369-61ab-4694-8c70-2456fa8b722b, digest iterations 128000
# Updating LUKS header of size 1024 on device /dev/mmcblk1p1
# Key length 32, device size 15659008 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/mmcblk1p1
# Key length 32, device size 15659008 sectors, header size 2050 sectors.
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Crypto backend (gcrypt 1.6.2) initialized.
# KDF pbkdf2, hash sha1: 546133 iterations per second.
# Key slot 0 use 266666 password iterations.
# Using hash sha1 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area.
# Calculated device size is 250 sectors (RW), offset 8.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-3214
# dm create temporary-cryptsetup-3214 CRYPT-TEMP-temporary-cryptsetup-3214 OF   [16384] (*1)
# dm reload temporary-cryptsetup-3214  OFW    [16384] (*1)
# Cookie value is not set while trying to call DM_DEVICE_RESUME ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm resume temporary-cryptsetup-3214  OFW    [16384] (*1)
# temporary-cryptsetup-3214: Stacking NODE_ADD (254,1) 0:6 0660
# temporary-cryptsetup-3214: Stacking NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3214: Processing NODE_ADD (254,1) 0:6 0660
# Created /dev/mapper/temporary-cryptsetup-3214
# temporary-cryptsetup-3214: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3214 (254:1): read ahead is 256
# temporary-cryptsetup-3214: retaining kernel read ahead of 256 (requested 256)
# Cookie value is not set while trying to call DM_DEVICE_REMOVE ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm remove temporary-cryptsetup-3214  OFT    [16384] (*1)
device-mapper: remove ioctl on temporary-cryptsetup-3214 failed: Device or resource busy
# Cookie value is not set while trying to call DM_DEVICE_REMOVE ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm remove temporary-cryptsetup-3214  OFT    [16384] (*2)
# temporary-cryptsetup-3214: Stacking NODE_DEL
# temporary-cryptsetup-3214: Processing NODE_DEL
# Removed /dev/mapper/temporary-cryptsetup-3214
# Key slot 0 was enabled in LUKS header.
# Updating LUKS header of size 1024 on device /dev/mmcblk1p1
# Key length 32, device size 15659008 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/mmcblk1p1
# Key length 32, device size 15659008 sectors, header size 2050 sectors.
# Releasing crypt device /dev/mmcblk1p1 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.




root@p2382_t186:~# cryptsetup luksOpen /dev/mmcblk1p1 data --debug
# cryptsetup 1.6.3 processing "cryptsetup luksOpen /dev/mmcblk1p1 data --debug"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/mmcblk1p1 context.
# Trying to open and read device /dev/mmcblk1p1.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/mmcblk1p1.
# Crypto backend (gcrypt 1.6.2) initialized.
# Reading LUKS header of size 1024 from device /dev/mmcblk1p1
# Key length 32, device size 15659008 sectors, header size 2050 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume data [keyslot -1] using [none] passphrase.
# Detected kernel Linux 3.18.21-tegra aarch64.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.28.0.
# Device-mapper backend running with UDEV support disabled.
# dm status data  OF   [16384] (*1)
# Interactive passphrase entry requested.
Enter passphrase for /dev/mmcblk1p1:
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Calculated device size is 250 sectors (RW), offset 8.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-3256
# dm create temporary-cryptsetup-3256 CRYPT-TEMP-temporary-cryptsetup-3256 OF   [16384] (*1)
# dm reload temporary-cryptsetup-3256  OFRW    [16384] (*1)
# Cookie value is not set while trying to call DM_DEVICE_RESUME ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm resume temporary-cryptsetup-3256  OFRW    [16384] (*1)
# temporary-cryptsetup-3256: Stacking NODE_ADD (254,1) 0:6 0660
# temporary-cryptsetup-3256: Stacking NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3256: Processing NODE_ADD (254,1) 0:6 0660
# Created /dev/mapper/temporary-cryptsetup-3256
# temporary-cryptsetup-3256: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-3256 (254:1): read ahead is 256
# temporary-cryptsetup-3256: retaining kernel read ahead of 256 (requested 256)
# Cookie value is not set while trying to call DM_DEVICE_REMOVE ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm remove temporary-cryptsetup-3256  OFT    [16384] (*1)
device-mapper: remove ioctl on temporary-cryptsetup-3256 failed: Device or resource busy
# Cookie value is not set while trying to call DM_DEVICE_REMOVE ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm remove temporary-cryptsetup-3256  OFT    [16384] (*2)
# temporary-cryptsetup-3256: Stacking NODE_DEL
# temporary-cryptsetup-3256: Processing NODE_DEL
# Removed /dev/mapper/temporary-cryptsetup-3256
Key slot 0 unlocked.
# Calculated device size is 15654912 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-ff6bc36961ab46948c702456fa8b722b-data
# dm create data CRYPT-LUKS1-ff6bc36961ab46948c702456fa8b722b-data OF   [16384] (*1)
# dm reload data  OFW    [16384] (*1)
# Cookie value is not set while trying to call DM_DEVICE_RESUME ioctl. Please, consider using libdevmapper's udev synchronisation interface or disable it explicitly by calling dm_udev_set_sync_support(0).
# Switching off device-mapper and all subsystem related udev rules. Falling back to libdevmapper node creation.
# dm resume data  OFW    [16384] (*1)
# data: Stacking NODE_ADD (254,1) 0:6 0660
# data: Stacking NODE_READ_AHEAD 256 (flags=1)
# data: Processing NODE_ADD (254,1) 0:6 0660
# Created /dev/mapper/data
# data: Processing NODE_READ_AHEAD 256 (flags=1)
# data (254:1): read ahead is 256
# data: retaining kernel read ahead of 256 (requested 256)
# Releasing crypt device /dev/mmcblk1p1 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] LUKS1 devmapper device mount issue
  2016-04-08 20:46 [dm-crypt] LUKS1 devmapper device mount issue Amith Kumar Ramachandra
@ 2016-04-09 12:36 ` Michael Kjörling
  2016-04-10  5:15 ` Amith Kumar Ramachandra
  1 sibling, 0 replies; 6+ messages in thread
From: Michael Kjörling @ 2016-04-09 12:36 UTC (permalink / raw)
  To: dm-crypt

On 8 Apr 2016 13:46 -0700, from amitnr@gmail.com (Amith Kumar Ramachandra):
> But when I format the device as ext4 and mount it at /mnt, I don't see the
> device mounted. The mount command itself did not fail. It gives me success
> (verified both from the return status and kernel dmesg logs) but the LUKS1
> device is not getting mounted.
> 
> However, when I create a crypt device using dmsetup, I am able to see and
> mount the volume1 device as expected.

You are answering just about every question I can think of _except_
the really important ones in your case; that is, the ones that pertain
to actually _mounting_ the file system:

 * Exactly how are you creating a file system on ("formatting") the
   device? Show us the command(s) and output, ideally in debug or
   verbose mode (for mke2fs, that's -v). Also, for completeness, show
   us how they relate to the luksCreate, luksOpen and dmsetup info.
   You may want to throw in a luksDump (on the raw device) too, for
   good measure.

 * How are you mounting the file system? Show us the command(s) and
   the output if any.

 * How do you conclude that the mount command succeeds but the file
   system isn't being mounted? Show us the command(s), the output if
   relevant, the relevant portion of the kernel logs and what you are
   doing to conclude that the file system _isn't_ being mounted.

If relevant, you may also want to show us the relevant portions of
your /etc/crypttab (or similar; the name might differ based on
distribution). It's possible that /proc/mounts (after you have tried
to mount the file system) could be of interest as well. Sharing those
should be safe because (at least on Debian, as far as crypttab goes)
they do not generally by themselves contain any sensitive information.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] LUKS1 devmapper device mount issue
  2016-04-08 20:46 [dm-crypt] LUKS1 devmapper device mount issue Amith Kumar Ramachandra
  2016-04-09 12:36 ` Michael Kjörling
@ 2016-04-10  5:15 ` Amith Kumar Ramachandra
  2016-04-10  8:10   ` Milan Broz
  1 sibling, 1 reply; 6+ messages in thread
From: Amith Kumar Ramachandra @ 2016-04-10  5:15 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 6034 bytes --]

Hi Michael,
 Thanks for getting back.

>>Exactly how are you creating a file system on ("formatting") the
>>device? Show us the command(s) and output, ideally in debug or
>>verbose mode (for mke2fs, that's -v).

root@tegra-t18x:~# mke2fs /dev/mapper/data -v mke2fs 1.42.9 (28-Dec-2013)
fs_types for mke2fs.conf resolution: 'ext2' Filesystem label= OS type:
Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks,
Stripe width=0 blocks 489600 inodes, 1956864 blocks 97843 blocks (5.00%)
reserved for the super user First data block=0 Maximum filesystem
blocks=2004877312 60 block groups 32768 blocks per group, 32768 fragments
per group 8160 inodes per group Superblock backups stored on blocks: 32768,
98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group
tables: done Writing inode tables: done Writing superblocks and filesystem
accounting information: done


After formatting the file system, I tried mounting it here
root@tegra-t18x:~# mount /dev/mapper/data /mnt/

But you can see /dev/mapper/data doesn't show up in the list of mounted
devices

root@tegra-t18x:~# mount /dev/mmcblk0p1 on / type ext4
(rw,relatime,data=ordered) proc on /proc type proc (rw,relatime) sysfs on
/sys type sysfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type
devtmpfs (rw,relatime,size=7297612k,nr_inodes=1824403,mode=755) tmpfs on
/dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts
(rw,relatime,gid=5,mode=620) tmpfs on /run type tmpfs
(rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs
(ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type
cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/debug type cgroup
(rw,nosuid,nodev,noexec,relatime,debug) cgroup on
/sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on
/sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer) debugfs on /sys/kernel/debug type
debugfs (rw,relatime) tmpfs on /tmp type tmpfs (rw) configfs on
/sys/kernel/config type configfs (rw,relatime) fusectl on
/sys/fs/fuse/connections type fusectl (rw,relatime) tmpfs on /var/volatile
type tmpfs (rw,relatime) tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=805528k,mode=700)


>>Also, for completeness, show us how they relate to the luksCreate, luksOpen and dmsetup info

root@tegra-t18x:~# dmsetup info
Name:              data
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      254, 0
Number of targets: 1
UUID: CRYPT-LUKS1-80230cc9085d4edca0425d1fe5fa3486-data


>>You may want to throw in a luksDump (on the raw device) too, for good measure.

root@tegra-t18x:~# cryptsetup luksDump /dev/mmcblk1p1
LUKS header information for /dev/mmcblk1p1

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      6b 22 6f 94 98 6a 9c ce c5 4e b4 8c 72 d8 0c 56 e1 c9 09 db
MK salt:        2a de 67 32 3f 3d 05 46 13 92 6f e7 6b 40 50 38
                d2 91 13 10 09 d0 62 07 d3 85 0b 77 61 bc 69 58
MK iterations:  128000
UUID:           80230cc9-085d-4edc-a042-5d1fe5fa3486

Key Slot 0: ENABLED
        Iterations:             266666
        Salt:                   98 76 2d 90 e2 a3 de 16 f8 43 5a be c6 93 5b 0b
                                74 b9 bf 9a e8 4a 9f 8b c1 e6 a1 27 59 0c 0c 22
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
root@tegra-t18x:~#


>>If relevant, you may also want to show us the relevant portions of
your /etc/crypttab

I do not have /etc/crypttab entries on my platform


>>It's possible that /proc/mounts (after you have tried
to mount the file system) could be of interest as well.

I have shared the outuput of /proc/mounts above.


I dumped ldd dmsetup and I see dmsetup uses almost the same set and
version of libraries cryptsetup uses. seems a mystery dmsetup created
devmapper device on formatting mounts fine but not crypsetup created
.....


Amith


On Fri, Apr 8, 2016 at 1:46 PM, Amith Kumar Ramachandra <amitnr@gmail.com>
wrote:

> Hi!
>
>  I am working on an armv8 embedded platform running 3.18 linux kernel. I
> am setting up disk encryption on a peripheral MMC card using
> cryptsetup-1.6.3 version.
>
> I am able to get through the first couple of steps of cryptsetup
> (luksFormat and luksOpen) without any issue. Commands here below:
>
> cryptsetup -v -y -c "aes-cbc-essiv:sha256" luksFormat /dev/mmcblk1p1
> --batch-mode --debug
> cryptsetup luksOpen /dev/mmcblk1p1 data --debug
>
> I can see the device /dev/mapper/data getting created as expected. I
> dumped its status and it looks fine from what I can see:
>
> root@p2382_t186:~# dmsetup info /dev/mapper/data
> Name:              data
> State:             ACTIVE
> Read Ahead:        256
> Tables present:    LIVE
> Open count:        0
> Event number:      0
> Major, minor:      254, 1
> Number of targets: 1
> UUID: CRYPT-LUKS1-ff6bc36961ab46948c702456fa8b722b-data
>
> But when I format the device as ext4 and mount it at /mnt, I don't see the
> device mounted. The mount command itself did not fail. It gives me success
> (verified both from the return status and kernel dmesg logs) but the LUKS1
> device is not getting mounted.
>
> However, when I create a crypt device using dmsetup, I am able to see and
> mount the volume1 device as expected.
>
> echo 0 `blockdev --getsize /dev/mmcblk1p1` crypt aes-cbc-essiv:sha256
> 0123456789abcdef0123456789abcdef 0 /dev/mmcblk1p1 0 | dmsetup create volume1
>
> I have attached the debug logs if you are interested.
>
> Could you pls let me know what I might be missing?
>
> Appreciate your help!
> Thanks,
> Amith
>
>

[-- Attachment #2: Type: text/html, Size: 9337 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] LUKS1 devmapper device mount issue
  2016-04-10  5:15 ` Amith Kumar Ramachandra
@ 2016-04-10  8:10   ` Milan Broz
  2016-04-10 21:04     ` Amith Kumar Ramachandra
  0 siblings, 1 reply; 6+ messages in thread
From: Milan Broz @ 2016-04-10  8:10 UTC (permalink / raw)
  To: Amith Kumar Ramachandra, dm-crypt

On 04/10/2016 07:15 AM, Amith Kumar Ramachandra wrote:

> I dumped ldd dmsetup and I see dmsetup uses almost the same set and
> version of libraries cryptsetup uses. seems a mystery dmsetup created
> devmapper device on formatting mounts fine but not crypsetup created
> .....

Hi,

I would say you are hitting some kernel problem here.

Please can you try

 - use new cryptsetup versision (1.7.1)

 - if dmestup works, please show the exact difference in mapping table.
(My guess it is only in offset reserved for header - you will need to decrease
device size as well. We are probably hitting some kernel bug when start of crypt
device is not aligned to mmc block.)

Could you try to create exact mapping table as LUKS does?
(Just activate LUKS using cryptsetup, check dmsetup table --showkeys
and repeat it with dmsetup.)
If you still see the problem, then kernel is the source of problem.

Anyway, there were a lot of changes related to aarch64, so if
you can use more recent kernel, it would be nice as well.
(According to log you are using Linux 3.18.21-tegra aarch64.)

Milan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] LUKS1 devmapper device mount issue
  2016-04-10  8:10   ` Milan Broz
@ 2016-04-10 21:04     ` Amith Kumar Ramachandra
  2016-04-12 12:20       ` Milan Broz
  0 siblings, 1 reply; 6+ messages in thread
From: Amith Kumar Ramachandra @ 2016-04-10 21:04 UTC (permalink / raw)
  To: Milan Broz; +Cc: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Hi Milan!

>> if dmestup works, please show the exact difference in mapping table.
Checked again. dmsetup does work and the devmapper device mounts fine
The mapping table from with dmsetup created device is

#dmsetup table
volume1: 0 15659008 crypt aes-cbc-essiv:sha256
000000000000000000000000000000000 179:33 0

cryptsetup created device doesn't mount. Here is the mapper table.
data: 0 15654912 crypt aes-cbc-essiv:sha256
0000000000000000000000000000000000000000000000000000000000000000 0 179:33
4096

>>Could you try to create exact mapping table as LUKS does?
Yes, I did. And the same table with dmsetup does mount the device. Here's  what
I did.

# cryptsetup -v -y -c "aes-cbc-essiv:sha256" luksFormat /dev/mmcblk1p1
--batch-mode
#echo 0 15654912 crypt aes-cbc-essiv:sha256
0123456789abcdef0123456789abcdef11111111111111111111111111111111 0 179:33
4096 | dmsetup create data
#dmsetup table --showkeys
data: 0 15654912 crypt aes-cbc-essiv:sha256
0123456789abcdef0123456789abcdef11111111111111111111111111111111 0 179:33
4096

You can see the table does match the cryptsetup one...

#mke2fs /devmapper/data
#mount /dev/mapper/data /mnt
#mount
....
....
/dev/mapper/data on /mnt type ext2 (rw,relatime)
And device is mounted.

>>use new cryptsetup versision (1.7.1)
I could switch and check I suppose. But here is one more data point ...

My environment where I run into issue with cryptsetup is on *Yocto root
file system, *an embedded distribution of Linux. However, when I switch to
Ubuntu 15.04 RFS(which is an alternate version I also boot sometimes) with
the same linux kernel, cryptsetup binary and libcryptsetup.so as Yocto, the
cryptsetup devmapper device mounts fine.
I then started narrowing down the differences b/w yocto and ubuntu in terms
of libraries etc... then I found that if I use the *systemd *executable in
/usr/lib/system/systemd from Ubuntu RFS in the Yocto, all yocto mount
problems go away. (not sure what systemd has got to do with cryptsetup and
mount)

If you are still with me, does this tell you anything at all? :)

Thanks,
Amith

[-- Attachment #2: Type: text/html, Size: 4379 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] LUKS1 devmapper device mount issue
  2016-04-10 21:04     ` Amith Kumar Ramachandra
@ 2016-04-12 12:20       ` Milan Broz
  0 siblings, 0 replies; 6+ messages in thread
From: Milan Broz @ 2016-04-12 12:20 UTC (permalink / raw)
  To: Amith Kumar Ramachandra; +Cc: dm-crypt

On 04/10/2016 11:04 PM, Amith Kumar Ramachandra wrote:
...
> You can see the table does match the cryptsetup one...
> 
> #mke2fs /devmapper/data #mount /dev/mapper/data /mnt #mount .... 
> .... /dev/mapper/data on /mnt type ext2 (rw,relatime) And device is
> mounted.

This is really strange (cryptsetup is basically just calling the same dm-ioctl in the end),
> 
>>> use new cryptsetup versision (1.7.1)
> I could switch and check I suppose. But here is one more data point
> ...
> 
> My environment where I run into issue with cryptsetup is on /Yocto
> root file system, /an embedded distribution of Linux. However, when I
> switch to Ubuntu 15.04 RFS(which is an alternate version I also boot
> sometimes) with the same linux kernel, cryptsetup binary and
> libcryptsetup.so as Yocto, the cryptsetup devmapper device mounts
> fine. I then started narrowing down the differences b/w yocto and
> ubuntu in terms of libraries etc... then I found that if I use the
> /systemd /executable in /usr/lib/system/systemd from Ubuntu RFS in
> the Yocto, all yocto mount problems go away. (not sure what systemd
> has got to do with cryptsetup and mount)
> 
> If you are still with me, does this tell you anything at all? :)

Looks like a magic :)
Really, no idea - systemd should just process /etc/crypttab devices.
It can be something stupid but without local reproducer it is hard to say...
If it is systemd, checking its log could help here.

Milan

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-04-12 12:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-08 20:46 [dm-crypt] LUKS1 devmapper device mount issue Amith Kumar Ramachandra
2016-04-09 12:36 ` Michael Kjörling
2016-04-10  5:15 ` Amith Kumar Ramachandra
2016-04-10  8:10   ` Milan Broz
2016-04-10 21:04     ` Amith Kumar Ramachandra
2016-04-12 12:20       ` Milan Broz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.