It would appear that udev has changed the locations of its binaries to /lib/udev/. This breaks multipath-tools as it expects the scsi_id and vol_id binaries to be in /sbin (where they were before). The current version of multipath-tools is basically unusable with the current udev versions with out manual hacking of /etc/multipath.conf. Some information as to how a Slackware user has been handling this are here: http://piterpunk.info02.com.br/extra/ Relevant excerpts are as follows: * Added a /sbin/scsi_id to /lib/udev/scsi_id symlink. This is needed to multipath. * Link /lib/udev/vol_id to /sbin/vol_id, vol_id is used by multipath, and need to be public The rationale for moving the binaries to /lib/udev is certainly beyond my knowledge of recent udev development but it would appear that simply making the symlinks in the udev package is an option. Of course, modifying the multipath package would also work. Reproducible: Always
@base-system: What do you think is the solution? linking these progs to /sbin? I do not know since what udev-version that has been in /lib/udev.
depends on what upstream typically does and/or other distros ...
As other distros do the same: Added vol_id and scsi_id symlinks to /sbin in udev-106-r3.
Reopening bug. (In reply to comment #3) > As other distros do the same: > Added vol_id and scsi_id symlinks to /sbin in udev-106-r3. These compability symlinks are gone with current udev's in the tree. I don't think we should be adding them back anymore. Instead multipath-tools should be fixed. The helpers live in `pkg-config --variable=udevdir udev` (udev.eclass and get_udevdir can be used)
*** Bug 468466 has been marked as a duplicate of this bug. ***
Looks like this is fixed in multipath-tools-0.4.9 already as it uses /lib/udev/scsi_id instead of /sbin/scsi_id everywhere.
