blkid is already run in 13-dm-disk.rules:IMPORT{builtin}="blkid" 60-persistent-storage.rules: IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}" 60-persistent-storage.rules: IMPORT{builtin}="blkid --noraid" 60-persistent-storage.rules:KERNEL!="sr*", IMPORT{builtin}="blkid" 64-md-raid.rules:IMPORT{program}="/sbin/blkid -o udev -p $tempnode" Please don't run blkid again unconditionally in 61-bcache.rules on _every_ block device
Thanks, I'm getting a better understanding on the processing of udev rules. Now I can imaging there's another issue. In 61-bcache.rules there's the following call: IMPORT{program}="/sbin/probe-bcache -o udev $tempnode" probe-bcache prints out the same "variables" that blkid does. Can this impact the other rules (that also assume that blkid already was used) because the variables are changed?
(In reply to Rolf Fokkens from comment #1) > Thanks, I'm getting a better understanding on the processing of udev rules. > > Now I can imaging there's another issue. In 61-bcache.rules there's the > following call: > > IMPORT{program}="/sbin/probe-bcache -o udev $tempnode" > > probe-bcache prints out the same "variables" that blkid does. Can this > impact the other rules (that also assume that blkid already was used) > because the variables are changed? yes, of course, this will impact the other rules!
(In reply to Harald Hoyer from comment #2) > (In reply to Rolf Fokkens from comment #1) > > Thanks, I'm getting a better understanding on the processing of udev rules. > > > > Now I can imaging there's another issue. In 61-bcache.rules there's the > > following call: > > > > IMPORT{program}="/sbin/probe-bcache -o udev $tempnode" > > > > probe-bcache prints out the same "variables" that blkid does. Can this > > impact the other rules (that also assume that blkid already was used) > > because the variables are changed? > > yes, of course, this will impact the other rules! the other rules, which come later in the sort order
In that case not only do I have to make rules file stop running blkid, but I also have to make probe-bcache stop rendering the same variables (until we can stop using probe-bcache). I'll get back on it later.
bcache-tools-0-0.10.20130827git.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bcache-tools-0-0.10.20130827git.fc20
Package bcache-tools-0-0.10.20130827git.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing bcache-tools-0-0.10.20130827git.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15965/bcache-tools-0-0.10.20130827git.fc20 then log in and leave karma (feedback).
bcache-tools-0-0.11.20130909git.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bcache-tools-0-0.11.20130909git.fc20
bcache-tools-0-0.11.20130909git.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Ran into the following situation: /dev/md1 = RAID1 (/dev/vda2, /dev/vdb2) = bcache backing device /dev/vdc1 = bcache caching device After bringing up /dev/md1 rule 61-bcache.rules should have kicked in and create /dev/bcache0. It should have, but it didn't. The cause was that in that particular situation (for /dev/md1) blkid is not executed in 13-dm-disk.rules.
bcache-tools-0-0.13.20130909git.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bcache-tools-0-0.13.20130909git.fc20
resorted to safety first: 61-bcache.rules does his own blkid. (Performance) optimizations can be done later.
Package bcache-tools-0-0.13.20130909git.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing bcache-tools-0-0.13.20130909git.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18121/bcache-tools-0-0.13.20130909git.fc20 then log in and leave karma (feedback).
After a brief discussion with Harold it became clear that moving 61-bcache.rules to 65-bcache.rules will solve the issue in a more efficient way. This will be fixed in alignment with dracut, Bug 1014625.
Actually moving to 69-bcache.rules. The bcache module will be removed from dracut and moved to bcache-tools for easier maintain consistency between the udev rules file and the dracut module.
The new package is ready: - removed execute blkid in 61-bcache.rules - moved 61-bcache.rules to 69-bcache.rules - now inluding /usr/lib/dracut/modules.d/90bcache/.. release will happen when new dracut is released, because the new bcache-tools "Conflict:" with current en older dracut packages that still include the 90bcache module.
The blkid builtin is marked run_once in udev-builtin-blkid.c, so I don't think there's any problem if it's used in builtin form. The rule order doesn't matter in this case.
dracut-034-7.git20131008.fc20,bcache-tools-0-0.14.20130909git.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dracut-034-7.git20131008.fc20,bcache-tools-0-0.14.20130909git.fc20
dracut-034-7.git20131008.fc20, bcache-tools-0-0.14.20130909git.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
bcache-tools-0-0.15.20131018git.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bcache-tools-0-0.15.20131018git.fc20
bcache-tools-0-0.15.20131018git.fc20 has been pushed to the Fedora 20 testing repository.
bcache-tools-0-0.15.20131018git.fc20 has been pushed to the Fedora 20 stable repository.