Peter Rajnoha schrieb:
Well, we are in the process of the changeover now. As Milan says, what we're trying to do is to centralize the udev support for DM devices. There were (are?) bits of the rules touching dm devices all over the udev rule sets from other packages.
Is a public discussion happening somewhere? I'd like to follow it or even participate, as I will be the one who has to fix up this mess in the end for Arch.
ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M -m %m", RESULT=="temporary-cryptsetup-*", OPTIONS="last_rule"Yes, something is definitely touching it. We have OPTIONS+="last_rule" in lvm/dm upstream udev rules for temporary-cryptsetup devices now. But the thing is that using last_rule is also a source of the complaints and people just do not want to see this (for example, this was also the first thing that Debian lvm maintainer removed and diverted from the upstream). Frankly, as for me, I would use last_rule here (as well as for hidden lvm devices and all devices that are temporary, hidden or special in any way so it has no meaning to process any other rules for them further). I asked Kay Sievers (from udev) what's his opinion about this and I got simple and straight answer from him: "I can not think of any valid use of last_rule. Also, it will still send out the events to listeners, as this can never be suppressed. last_rule should probably just be removed, as is breaks all sorts of things and creates an inconsistent behavior."
If there is no mechanism to tell udev to ignore a certain device, shouldn't it be possible to tell the dm subsystem to not raise a uevent for a device? I imagine setting a "temporary" flag.
I've posted patches on lvm-devel that introduce udev flags with which we
can disable certain parts of the udev rules. Then these flags could be
checked for and inappropriate parts of udev rules skipped (considering upstream):
DM_UDEV_FLAG_DISABLE_DISK_RULES - to disable 12-dm-disk.rules
DM_UDEV_FLAG_DISABLE_SUBSYSTEM_RULES - disable any subsystem rules, like 11-lvm.rules
for LVM... The same could be applied for any
other subsystem supplying its own rules.
These flags could be set directly in libdevmapper for each device being processed
(but that's only for kernels >= 2.6.31, because we use cookie values to pass this
information and they were introduced only in 2.6.31). Or we can set these flags
directly in udev rules (like I'm proposing now on lvm-devel where I removed
last_rule for temporary-cryptsetup and like and set these flags directly).
I don't get how this is better than last_rule, except it is more work and adds extra complexity. All I want is that temporary devices are being left alone completely.
Your quote from Kay Sievers also mentions events being sent to listeners, which can "never be suppressed" - the fact is that we want/need to suppress them - what you suggest doesn't change that.
Anyway, looking at the udev manpage, there seems to be a "ignore_device" option, is that better than last_rule? Shouldn't it fit our situation better? Or is it yet another option we shouldn't use?
But such solution (I mean the one without last_rule) expects that everybody else will be playing device-mapper rules as well. It means always checking these flags and skip the rules if it is instructed to do so. This solution is much cleaner from udev perspective since it does not use that last_rule functionality...
Not only dm-specific rules but all rules everywhere need to be aware of this. There's also site/user-specific rules which could break and and and - as I said, extra complexity.
I know, the solution with OPTIONS+="last_rule" would be much easier, since it ignores any rules further, but at least this way we can spot all the places where dm devices are touched by the rules and we can send a notice to those maintainers. Otherwise this would be hidden forever.
Good point - but I still think that telling udev to leave the device alone completely feels like the right thing to do.
What is this remove error caused by, if not by some application being called from udev blocking access? Note that there are no temporary-cryptsetup-* volumes left after luksOpen.No idea - but always I debubugged it, it was initiated from udev event through udev rule...hmm, this is bound to the actual ruleset that is used in each distro. Each one should be cleaned and any help is a welcome, really. Also, if you spot any strange behaviour related to DM devices and udev, just feel free to CC me. Also, I would be very glad if all the rules in all distros would be in sync with upstream ones. If we could achieve that, it would be great, so we would have one base and we don't have to solve various problems over and over again.
We're trying to do that, but I think there are some legacies in our packages - device-mapper didn't have upstream udev rules in the past, so we added one to get the /dev/mapper/* devices created. That rule is still there, and probably nobody checked if upstream included something themselves.
..this is Arch Linux, right? I'll take a look...
Indeed.Our udev rules are a big mess right now for various reasons I wanted to address soon. All I can say is that the only dm-specific rule is (included in the device-mapper package):
ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M -m %m", NAME="mapper/%c", MODE="0600", SYMLINK+="disk/by-name/%c"
Then, the devicekit package also has some rules specific to dm, which I didn't look at yet (I guess they are just the upstream devicekit rules, we tend to not change them when possible).
The problematic rules are the ones that will just touch any block device - none of those has an explicit check to include or exclude dm-*. I think this should only be blkid, but I am not sure.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
