Поймал на e2k, но актуально и на x86_64 как минимум; вероятно, стоит перенести зависимость от dmsetup из общего пакета multipath-tools конкретно в подпакет kpartx (который требуется multipath-tools). Если запустить kpartx -a -s /dev/loop0 при отсутствующем dmsetup, он зависнет: # kpartx -a -s /dev/loop0 ^C # strace -ff kpartx -a -s /dev/loop0 [...] ioctl(3, DM_DEV_STATUS, 0x28d80) = 0 ioctl(3, DM_TABLE_LOAD, 0x2cdb0) = 0 open("/dev/urandom", O_RDONLY) = 4 read(4, "\255\264", 2) = 2 semget(223196333, 1, IPC_CREAT|IPC_EXCL|0600) = 32769 semctl(32769, 0, IPC_64|SETVAL, 0xc2dfffb3c148) = 0 semctl(32769, 0, IPC_64|GETVAL, 0xc2dfffb3c148) = 1 close(4, ) = 0 semop(32769, 0xc2dfffb3c198, 1) = 0 semctl(32769, 0, IPC_64|GETVAL, 0xc2dfffb3c148) = 2 ioctl(3, DM_DEV_SUSPEND, 0x28d60) = 0 semget(223196333, 1, 0) = 32769 semctl(32769, 0, IPC_64|GETVAL, 0xc2dfffb3c1b8) = 2 semop(32769, 0xc2dfffb3c208, 1) = 0 semop(32769, 0xc2dfffb3c250, 1^C <unfinished ...> Если убрать -s -- завершится нормально, при этом образуется только /dev/loop0p1 (если образ содержал таблицу разделов с одним разделом, как в этом случае), но не /dev/mapper/loop0p1: # kpartx -a /dev/loop0 # find /dev -name loop0p1 /dev/loop0p1 # _ При попытке отформатировать /dev/loop0p1 получаем облом: # mkfs.ext2 /dev/loop0p1 mke2fs 1.42.13 (17-May-2015) /dev/loop0p1 is apparently in use by the system; will not make a filesystem here! # strace -ff mkfs.ext4 /dev/loop0p1 [...] stat("/dev/loop0p1", {st_mode=S_IFBLK|0660, st_rdev=makedev(259, 0), ...}) = 0 open("/dev/loop0p1", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy) write(2, "/dev/loop0p1 is apparently in us"..., 49/dev/loop0p1 is apparently in use by the system; ) = 49 write(2, "will not make a filesystem here!"..., 33will not make a filesystem here! ) = 33 exit_group(1) # _ После установки dmsetup всё работает ожидаемым образом. Понятно, что кривой код, который не делает нужных проверок, а молча ожидает наличия фактически требуемого бинарника -- неправ и в другом месте, но...
Ситуация строго обратная: когда поддержка devmapper'а полностью выпилена из системы, подобных проблем вообще не возникает. Просто нужно понимать, какие риски он создает, а главное - где и в каких ситуациях его допустимо использовать.
root@evil:~ # kpartx -a /dev/loop2 /dev/mapper/control: open failed: No such device Incompatible libdevmapper 1.02.137-git (2016-11-30) and kernel driver (unknown version). device mapper prerequisites not met Что делает libdevmapper на рабочей станции - мне непонятно.
