Description of problem: LUKS device need during opening temporary device which contains obfuctated master key. This device is marked private (with all udev flags) and nobody must read from this device except cryptsetup itself. IIRC there was a workaround in HAL, which excluded temporary-cryptsetup-* devices, unfortunately this workaround now doesn't work, because device node changed and /dev/mapper/temporary-* is now symlink to /dev/dm-X device. (This change was requested by udev upstream when integrating udev in DM.) You should parse /sys/block/dm-X/dm/name (or use DM_UUID which is CRYPT-TEMP-*) instead of parsing node name or used udev variable like other rules do. The same bug appeared in Debian, see my comment there http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586286#40 Version-Release number of selected component (if applicable): hal-0.5.14-3.fc14.x86_64 How reproducible: cryptsetup luksOpen for some device on rawhide. Sometimes, when hal i sreally slow in scan, you can see in --debug this: # cryptsetup 1.1.3 processing "cryptsetup luksOpen /dev/sdb2 x --debug ... # dm remove temporary-cryptsetup-16370 OF [16384] device-mapper: remove ioctl failed: Device or resource busy ... # WARNING: other process locked internal device temporary-cryptsetup-16370, retrying remove. # WARNING: Process PID 16374 (hald-probe-volu) [PPID 1277 (hald-runner)] spying on internal device /dev/dm-6. Expected results: Nobody must touch crytsetup internal device, it contains obfuscated key. Moreover it blocks cryptsetup from operation (it will recover but with error messages).
Created attachment 431413 [details] proposed patch/workaround Proposed patch checks flag which udev rules set for internal devices. It should work with all new udev rules (Peter can say exact version). Please apply this, thanks.
(In reply to comment #1) > (Peter can say exact version). That should be lvm2 v2.02.54 (device-mapper v2.02.39).
(In reply to comment #2) > That should be lvm2 v2.02.54 (device-mapper v2.02.39). ..ehm, device-mapper v1.02.39, I mean :)
(In reply to comment #1) > Created an attachment (id=431413) [details] > proposed patch/workaround > > Proposed patch checks flag which udev rules set for internal devices. It should > work with all new udev rules (Peter can say exact version). > > Please apply this, thanks. Looks okay to me, but could you please send this to the upstream hal mailing list and then I'll ack it, and commit it upstream as well. Thanks. Richard.
Done, I hope it is correct list :-) http://article.gmane.org/gmane.linux.hotplug.devel/15936
Hi Milan, the hal mailing list is at http://lists.freedesktop.org/mailman/listinfo/hal
(In reply to comment #6) > http://lists.freedesktop.org/mailman/listinfo/hal thanks, resent there but list is moderated, so waiting for in queue...
*** Bug 614989 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Any progress here?
I'm raising severity: it's not just an anoying message, it seems to cause disk corruption. My setup: - I'm running Fedora 14 with all updates. - I create incremental backups of partitions - I mount an encrypted USB stick - I rsync the incrementals to the USB stick - I cmp the original data with the new data (actually this is a left-over from the time I copied the data to tape -- for which I'm grateful) Since a couple of days I get the message "device-mapper: remove ioctl failed: Device or resource busy" while mounting the encrypted USB stick, and in the end the verification fails. Investigation shows that the data that rsync writes to the USB stick is corrupted. This is reproducible, though the exact corruption differs. I tried several USB sticks, reformatted them and so on. Still no success. When I run this procedure with HAL disabled, there's no "device-mapper" message and rsync and verification complete without problems. I have attached the log of the copy/compare process. The backup copy and verify process has been in production for a couple of years and never showed any signs of strange failures. I cannot explain why the failures started on August 19. I did perform a system update on August 16, but if this was the cause I'd expect failures starting August 17, not a few days later. Since I use encrypted disks for several purposes, I'm very worried.
Created attachment 519202 [details] Log of the rsync/verify process failing
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping