Bug 1828617

Description of problem:


Version-Release number of selected component (if applicable):

This was observed with the 2.03.07-1ubuntu1 package on Ubuntu 20.04 but I don't think this code has changed in a long time.

How reproducible:

100%

Steps to Reproduce:
1. Have a system with multipath nodes:

# ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Apr 24 05:57 control
lrwxrwxrwx 1 root root       7 Apr 27 22:26 mpatha -> ../dm-0
lrwxrwxrwx 1 root root       7 Apr 27 22:26 mpatha-part1 -> ../dm-1


2. Remove the nodes: 

# rm -rf /dev/mapper/mpath*

3. Run vgscan:

# vgscan --mknodes


Actual results:

/dev/mapper is now full of block devices, not symlinks:

# ls -l /dev/mapper/
total 0
crw------- 1 root root  10, 236 Apr 24 05:57 control
brw-rw---- 1 root disk 253,   0 Apr 27 22:28 mpatha
brw-rw---- 1 root disk 253,   1 Apr 27 22:28 mpatha-part1


Expected results:

I would not expect scanning for vgs to do anything with device mapper nodes that are not related to lvm.

Additional info:

It's fairly easy to see why this happens:

Passing --mknodes to vgscan means it calls vgmknodes.
vgmknodes calls lv_mknodes(cmd, NULL)
lv_mknodes(cmd, NULL) calls dm_mknodes(NULL)
dm_mknodes(NULL) makes nodes for all device mapper nodes

This causes problems because in an installer, we watch for udev block events, and call vgscan to see if any vgs have appeared. This sometimes races with udev's own event processing to the extent that udev does not create links in /dev/mapper because the block devices are already there. Later code assumes the udev created symlinks and gets confused.