When starting /etc/init.d/multipathd, the multipath devices are set up in /dev/mapper as expected, but the partitions on each device are not seen. The much simpler udev rules with multipath-tools-0.4.7 run kpartx and the partitions are populated correctly. Reproducible: Always Steps to Reproduce: 1. Configure /etc/multipath.conf using a disk that has at least one partition. 2. /etc/init.d/multipathd start 3. ls /dev/mapper Actual Results: Whole disk devices are listed (e.g., raid1) Expected Results: Whole disk devices and their partitions are listed (e.g., raid1 and raid1-part1) Downgrading to multipath-tools-0.4.7 gives the expected results. I looked into this a bit by running udevadm test /block/dm-0 and it looks like the tools provided by device-mapper-1.02.24-r1 produce different output than what /etc/udev/rules.d/66-kpartx.rules expects. 66-kpartx.rules contains this: ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" but dmsetup adds this to the environment instead: DM_TABLE_LIVE=1 I changed the rule to look for DM_TABLE_LIVE=1 instead, which allows more of the rules to execute, but still no partition information comes up, and the reason is beyond my understanding of udev/multipath/device-mapper.
need more info. Can you provide your /proc/partitions with multipath active, as well as the udev info dump for the multipath device? In both 0.4.7 AND 0.4.8-r1.
Created attachment 209195 [details] command results with multipath 0.4.7-r2
Created attachment 209201 [details] command results with multipath 0.4.8
Here are the commands for the differents multipath version. But with multipath 0.4.8 and boot on SAN I can't add mapping of /usr and /var (in initramfs) so I cannot run parted and multipath (libaio is not present after boottime).
The problem is completely outside of udev. kpartx seems to break parsing the extended partition table explicitly. # kpartx -l /dev/sda sda1 : 0 524288 /dev/sda 128 sda2 : 0 10485760 /dev/sda 524416 sda3 : 0 1453828654 /dev/sda 11010176 sda5 : 0 50331713 /dev/dm-2 63 sda6 : 0 1403496815 /dev/dm-2 50331839 # sfdisk -xqL -d /dev/sda Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. # partition table of /dev/sda unit: sectors /dev/sda1 : start= 128, size= 524288, Id=83, bootable /dev/sda2 : start= 524416, size= 10485760, Id=83 /dev/sda3 : start= 11010176, size=1453828654, Id= 5 /dev/sda4 : start= 0, size= 0, Id= 0 /dev/sda5 : start= 11010239, size= 50331713, Id=82 - : start= 61341952, size=1403496878, Id= 5 - : start= 11010176, size= 0, Id= 0 - : start= 11010176, size= 0, Id= 0 /dev/sda6 : start= 61342015, size=1403496815, Id=8e - : start= 61341952, size= 0, Id= 0 - : start= 61341952, size= 0, Id= 0 - : start= 61341952, size= 0, Id= 0
0.4.8-r2 has a fix for kpart's bad extended partition handling now. I've submitted it to upstream as well, as it's present in their git tip as well. As for the DM_TABLE_STATE rule, that's still what upstream has, and while it doesn't actually do anything, I think it's not relevant to the real matter in this bug.
Partitions not appearing is dues to checking ENV{DM_STATE} instead of ENV{DM_STATUS} on lines 29 and 31 of 66-kpartx.rules.