Issues with cold-plugged devices and systemd/udev

[Richard Weinberger <richard@sigma-star.at>]

Hello!

As I understand it, the current Device Mapper concept requires that udev
be up and running while a new DM device is being configured, as mandated by
all udev rules.

I'd like to highlight a case where this requirement is not met and explore
possible workarounds or solutions.

Configuring DM devices, such as dm-crypt, before systemd (and udev) starts
is common in embedded systems. This typically occurs within a minimalist
initramfs or via the dm-mod.create= kernel parameter.

In most cases, this issue goes unnoticed because users are only configuring
the root filesystem. However, our scenario is different: all dm-crypt
devices are configured before real userspace starts, and userspace later
mounts them in various ways. These devices are also listed in /etc/fstab, 
which is processed by systemd.

Since the DM device is created before udev is up, the cold-plugged DM has the following
properties:

$ udevadm info /dev/mapper/cr_sdb
P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 252:0
N: dm-0
L: 0
Q: 12
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: DISKSEQ=12
E: MAJOR=252
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=56919818
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

As a result, only the raw DM device is present, but systemd does not recognize
it as ready. Consequently, the mount unit dependency is missing, causing the
boot process to fail.

In a discussion with Martin Wilck, he suggested that suspending and resuming
the DM device might trigger the appropriate udev rule processing. Thanks a lot
for that!

Indeed, after running:

dmsetup suspend /dev/mapper/cr_sdb && dmsetup resume /dev/mapper/cr_sdb

udev properly processes the DM device, and systemd recognizes it as ready:

$ udevadm info /dev/mapper/cr_sdb
P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 252:0
N: dm-0
L: 0
S: mapper/cr_sdb
S: disk/by-id/dm-name-cr_sdb
S: disk/by-uuid/f1b7c2ce-55cd-4f85-a192-cb43f55a781d
S: disk/by-id/dm-uuid-CRYPT-PLAIN-cr_sdb                                                                                                                                                                          
Q: 12                                                                                                                                                                                                             
E: DEVPATH=/devices/virtual/block/dm-0                                                                                                                                                                            
E: DEVNAME=/dev/dm-0                                                                                                                                                                                              
E: DEVTYPE=disk                                                                                                                                                                                                   
E: DISKSEQ=12                                                                                                                                                                                                     
E: MAJOR=252                                                                                                                                                                                                      
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=56919818
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_ACTIVATION=1
E: DM_NAME=cr_sdb
E: DM_UUID=CRYPT-PLAIN-cr_sdb
E: DM_SUSPENDED=0
E: DM_UDEV_RULES_VSN=2
E: ID_FS_UUID=f1b7c2ce-55cd-4f85-a192-cb43f55a781d
E: ID_FS_UUID_ENC=f1b7c2ce-55cd-4f85-a192-cb43f55a781d
E: ID_FS_VERSION=1.0
E: ID_FS_BLOCKSIZE=4096
E: ID_FS_LASTBLOCK=131072
E: ID_FS_SIZE=536870912
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: DEVLINKS=/dev/mapper/cr_sdb /dev/disk/by-id/dm-name-cr_sdb /dev/disk/by-uuid/f1b7c2ce-55cd-4f85-a192-cb43f55a781d /dev/disk/by-id/dm-uuid-CRYPT-PLAIN-cr_sdb
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

While I can live with this workaround, I'd like to ask for further input.
Is there a simpler solution available?

I'm also open to implementing changes in either the kernel or udev rules
to better handle this corner case.

If no alternative exists, I'd kindly ask that this workaround be recognized
and preserved to ensure that unconventional DM setups, such as those in
embedded systems, continue to function properly.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y