Bug 216538 - Lack of /dev/dm-? breaks hal's encrypted/LUKS volume support
Lack of /dev/dm-? breaks hal's encrypted/LUKS volume support
Status: CLOSED DUPLICATE of bug 209590
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
: Regression
: 213801 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-20 18:21 EST by W. Michael Petullo
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-17 06:25:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2006-11-20 18:21:27 EST
Description of problem:
When I create a dm-crypt/LUKS device using cryptsetup a /dev/dm-? device node is
no longer created.  This node was using by hal to determine the relationship
between a dm-crypt device and its backing device.  As a result, dm-crypt/LUKS
devices are no longer mounted automatically by hal and friends.

I have been tracking Rawhide until Fedora Core 6.  I am not sure when my system
stoped creating /dev/dm-? device nodes.  I am also unsure what component was
responsible for this in the past.

Version-Release number of selected component (if applicable):
hal-0.5.8.1-4.fc6

How reproducible:
Every time

Steps to Reproduce:
1. Create a LUKS-encrypted removable disk
2. Plug the disk into a Fedora system
  
Actual results:
The hal and friends subsystem will detect a LUKS disk, prompt for a password and
setup a dm-crypt device.  However, volume.crypto_luks.clear.backing_volume is
not set for the reasons listed above.

Expected results:
volume.crypto_luks.clear.backing_volume should be set and the device should be
mounted.

Additional info:
I am using Fedora Core 6, with updates as of 18 Nov 06.

I found this bug when trying to work on my encrpyted root mkinitrd patch, bug
#124789.

See hald/linux/coldplug.c and hald/linux/blockdev.c for references to /dev/dm-?.
Comment 1 Michael Hampton 2006-11-20 19:26:19 EST
This looks like a duplicate of bug 213801. :)
Comment 2 Michael Hampton 2006-11-20 20:07:30 EST
*** Bug 213801 has been marked as a duplicate of this bug. ***
Comment 3 W. Michael Petullo 2006-11-27 17:59:05 EST
This should fix the problem:

Comment out "KERNEL=="dm-[0-9]*", OPTIONS+="ignore_device"" in
/etc/udev/rules.d/50-udev.rules.  Restart udevd.  udevd should now create
/dev/dm-? nodes.

I am not sure why udev has this rule.
Comment 4 David Zeuthen 2006-12-01 10:40:05 EST
Reassigning.
Comment 6 W. Michael Petullo 2006-12-28 20:23:59 EST
Harald, do you have any comment onthis udev rule?
Comment 7 Harald Hoyer 2006-12-29 06:23:20 EST
will release udev update soon.
Comment 8 W. Michael Petullo 2007-01-11 18:03:48 EST
Red Hat Magazine is scheduled to publish an article that talks about these
encryption features in hal.  The publication date is estimated to be 25 January
07.  Could you release a fix in udev before then?
Comment 9 Harald Hoyer 2007-01-12 09:44:29 EST
already in the updates-testing repo
Comment 10 W. Michael Petullo 2007-01-12 18:29:30 EST
I tried udev-095-17.fc6.ppc.rpm from the updates-testing repository. 
Unfortunately, I still find that /dev/dm-* devices are not created by udevd. 
The following line seems to remain the culprit:

KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device"

It seems that "ACTION==add" was added to this line, but the problem from before
remains.

With this line commented out, udevd creates /dev/dm-* as I would expect.
Comment 11 Jens Lautenbacher 2007-01-16 21:16:46 EST
Confirmed. Still needed to patch by hand here, too :-(
Comment 12 Harald Hoyer 2007-01-17 06:25:59 EST

*** This bug has been marked as a duplicate of 209590 ***
Comment 13 Nils Philippsen 2007-07-24 05:26:06 EDT
Note that this is fixed in F7. I can use my encrypted LUKS volumes just fine there.

Note You need to log in before you can comment on or make changes to this bug.