udev rules don't create device nodes for readonly devices

[Dagfinn Ilmari Mannsåker]

The udev rules file skips to the end if DM_STATE != ACTIVE, but this breaks dmsetup luksOpen, which initially creates the device node read-only. The below patch fixes this.

--- /etc/udev/rules.d/65-dmsetup.rules~ 2007-05-21 22:53:44.000000000 +0100
+++ /etc/udev/rules.d/65-dmsetup.rules 2007-05-27 00:43:34.000000000 +0100
@@ -8,7 +8,7 @@

 # Skip inactive devices, as well as snapshot and error tables
 IMPORT{program}="/sbin/dmsetup export -j%M -m%m"
-ENV{DM_STATE}!="ACTIVE", GOTO="dmsetup_end"
+ENV{DM_STATE}!="ACTIVE|READONLY", GOTO="dmsetup_end"
 ENV{DM_TARGET_TYPES}=="|*snapshot*|*error*", GOTO="dmsetup_end"

 # Make the /dev/mapper name a symlink to the real name, also include in by-id

[Scott James Remnant (Canonical) (canonical-scott)]

Could you explain why you think this is a bug?

This prevents vol_id being run on read-only devices, and thus prevents any filesystem on them from being automatically used by udev.

Isn't this exactly what this flag is supposed to do?

[Dagfinn Ilmari Mannsåker (ilmari)]

It makes 'cryptsetup luksOpen' hang for 3 minutes while waiting for /dev/mapper/temporary-crypsetup-<pid> to appear before it times out with the message "Rendezvous with udev timed out for 'temporary-cryptsetup-27258'; stat failed: No such file or directory" (it does succeed after the timeout, though).

Here is an ltrace dump, of crypstsetup luksOpen on a test device.

[Jamie Lokier (jamie-shareable)]

I was about to report this exact same bug, and my patch is the same too.
Without the patch, boot pauses for 3 minutes on a system with encrypted /home.

What normally happens is you enter the disk passphrase, and it would say it's unlocked and continue booting immediately. But recently, you enter the passphrase and then there are no messages after you press enter for 3 minutes. Then it continues, starting with the udev rendezvous error message.

Even "failsafe" boot pauses for 3 minutes before giving you a root shell.

Unless you know to wait, it seems like boot has hung - I did many reboot until I figured out that entering the _wrong_ passphrase gets me to a root shell in failsafe mode, where I could trace the problem.

The patch to udev's 65-dmsetup.rules fixes this problem.

(I'm not sure why cryptsetup needs to rendezvous with udev at all, though. It seems to be fine when that fails. Maybe it would be better to remove that from cryptsetup, making boot a bit faster?)

Scott, I think your comment is the wrong way around. _Without_ this patch, vol_id isn't run on read-only devices - at least, not by dmsetup.rules. If you want vol_id to run on read-only devices so they are mounted by udev, you need this patch, I think.

[Jamie Lokier (jamie-shareable)]

I see the latest dmsetup has fixed this in a different way.

It always creates the device node in /dev/mapper, so cryptsetup should be fine with that (I haven't tried it though).

The latest version doesn't run vol_id for read-only devices, as before Is that right, I wonder? At least the cryptsetup problem is fixed now, I think.

[Scott James Remnant (Canonical) (canonical-scott)]

devmapper (2:1.02.18-1ubuntu6) gutsy; urgency=low

  * Don't run vol_id on devices with empty tables.
  * But do run vol_id on devices with tables containing snapshot or
    snapshot-origin entries, since these are the final result, not the
    transient pieces.
  * Also run vol_id on read-only devices. LP: #117089.
  * Give devices with snapshot-origin in their tables a slightly higher
    link priority, so they win out of all the LVM devices (UUID will point to
    the base device, not any snapshots) but still not higher than the
    underlying devices so real hardware wins.

 -- Scott James Remnant <email address hidden> Tue, 29 May 2007 20:26:00 +0100