cannot initialize device-mapper

Bug #93568 reported by William Cybriwsky on 2007-03-19
Affects Status Importance Assigned to Milestone
cryptmount (Ubuntu)

Bug Description

Binary package hint: cryptmount

"Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.08 (2006-07-17)(compat) and kernel driver
failed to initialize device-mapper task"

This is required to mount encrypted volumes; the package is useless without this.

1) create a file to host the encrypted partition using dd if=/dev/null of=/tmp/myimage bs=1M size=100
2) add an entry in /etc/cryptmount/cmtab:
myimage {
               dev=/tmp/myimage dir=/home/myimage
               fstype=ext2 fsoptions=defaults cipher=twofish
3) generate a decryption key: cryptmount --generate-key 32 myimage
4) give the command: cryptmount --prepare myimage

RW Penney (rwpenney) wrote :

I think this is really a problem with the libdevmapper package (1.02.08) in the ubuntu-7.04-beta release which I have tried this on. The problem seems to be entirely due to the failure to load the main device-mapper kernel-module either on system boot-up or when libdevmapper is first used. The debian libdevmapper packages (1.01, 1.02) include a script in /etc/init.d which automatically modprobes dm-mod (and a few other modules). An alternative approach would be to modify libdevmapper itself to execute this modprobe itself.

From my experiments on ubuntu-7.04-beta, it appears that solely executing:
    modprobe dm-mod
(as root) is sufficient to get cryptmount working fine. Clearly this is not ideal if one wishes to use cryptmount, as intended, without becoming root. However, as an interim fix, one could add a line of the form:
    modprobe dm-mod || true
(and perhaps "modprobe dm-crypt || true" as well, to be on the safe side) to either /etc/rc.local or to /etc/init.d/cryptmount (just before the line starting "test -x ${CM_EXE}...."). Both of these should ensure that the necessary kernel modules are loaded at system startup. Provided the modules don't get automatically or manually removed, this should be sufficient to ensure that cryptmount behaves as expected.

However, I must reiterate, that I believe that this bug is far better addressed through modifications to the libdevmapper package.

RW Penney (rwpenney) wrote :

This issue has been patched in cryptmount-2.1 with a precautionary "modprobe" in the /etc/init.d scripts.
An updated debian package (2.1-1) has just been uploaded to unstable.

Martin Pitt (pitti) wrote :

Fixed in Hardy now, thank you!

Changed in cryptmount:
status: New → Fix Released
Martin Pitt (pitti) wrote :

This is a patch from upstream to fix the issue in Hardy. If somebody wants to do an SRU, please go ahead (patch sanctioned).

Changed in cryptmount:
assignee: nobody → warp10
status: New → In Progress
Andrea Colangelo (warp10) wrote :

Built, installed and tested under Gutsy.

description: updated
Changed in cryptmount:
assignee: warp10 → nobody
status: In Progress → Confirmed
Martin Pitt (pitti) wrote :

Sponsored and accepted into gutsy-proposed, please test.

Changed in cryptmount:
status: Confirmed → Fix Committed
Daniel Schwitzgebel (schwitzd) wrote :

work for me

Luca Falavigna (dktrkranz) wrote :

Fix works for me on Gutsy.

Minimum aging period of seven days elapsed and two persons confirmed fix is good.
Marking verification-done as per (old policy)

Martin Pitt (pitti) wrote :

Copied to -updates.

Changed in cryptmount:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers