Comment 3 for bug 1959077

Revision history for this message
Pierre Equoy (pieq) wrote : Re: disk/disk_stress_ng_* fail on encrypted partitions, but not always

In /usr/lib/udev/rules.d/55-dm.rules we can see the following:

------------------------------------------------------------
(...)
# Device created, major and minor number assigned - "add" event generated.
# Table loaded - no event generated.
# Device resumed (or renamed) - "change" event generated.
# Device removed - "remove" event generated.
#
# The dm-X nodes are always created, even on "add" event, we can't suppress
# that (the node is created even earlier with devtmpfs). All the symlinks
# (e.g. /dev/mapper) are created in right time after a device has its table
# loaded and is properly resumed. For this reason, direct use of dm-X nodes
# is not recommended.
ACTION!="add|change", GOTO="dm_end"

(...)

ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*", SYMLINK+="mapper/$env{DM_NAME}"

(...)

LABEL="dm_end"
------------------------------------------------------------

This is aligned with the findings in previous comment: on the first boot, the disk is "added" for the first time, so a bunch of information is generated by udev (SYMLINK, ENV{DM_NAME}, etc.). On subsequent boots, the disk remains the sam, so no "add" nor "change" events are generated, so udev skips all the steps and goes directly to the bottom of the rules file ("dm_end").

Now, that comment is saying it is not recommended to use dm-X nodes directly. I'm wondering if we could find a better way to do this in Checkbox, then.