severity 403687 important thanks On Sun, Jan 14, 2007 at 11:08:53PM +0100, David Härdeman wrote: > I'll forward the same message to this bug that I forwarded to #406697 > (which is now closed). Feel free to substitute "cryptsetup" for > lvm or any other suitable packages in the text below...
This bug report is filed against lvm2, not against cryptsetup? > udev currently receives uevents from the kernel when a new device-mapper > device mapping is created and creates a /dev/dm-* node. libdevmapper > knows when devices are created/removed and creates the /dev/mapper/* > nodes. > However, the kernel will not (AFAIK) send uevents when device-mapper > mappings are renamed, changed or removed, so udev is not able to remove > the devices when appropriate. > So the "fix" would be to add support for those uevents to the kernel > and to change udev to act on them. Ideally it would create the /dev/dm-* > devices and symlinks in /dev/mapper/*. > Once that is in place, node creation can be removed from libdevmapper > (meaning it will have to wait for the nodes to magically appear > instead). > There is a writeup on this with some more details at: > https://wiki.ubuntu.com/UdevDeviceMapper > However, I can't see that anything needs to be done in cryptsetup > (except making sure that all works when/if this behaviour is changed in > libdevmapper). Ok, between Frans's messages and this one, I don't see any reason we should consider resolving this bug a blocker for the release. The most impact anyone has reported that these not-deleted device nodes have is to generate some warning messages on shutdown. Aside from the practical problem of trying to shove in changes to uevent handling this late, a few messy warning messages for a particular use case isn't anything that we can't live with. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
