Comment 7 for bug 1551937

So, the gist of this problem:
1.) Curtin runs in the install environment, which does not have mutipath kernel modules or user space utility.
 even if it did, it would not be guaranteed that it was the same version as the target's multipath
2.) curtin generates a /etc/multipath/bindings containing the root device as 'mpath0' (name doesnt matter) and then sets system to boot with 'root=/dev/mapper/mpath0' and enables uses user_friendly_names to get that read.
3.) /etc/multipath/bindings is line formated with space delimited fields. curtin uses '/lib/udev/scsi_id --whitelisted --device=/dev/sda' to read the wwid.
4.) some wwid have spaces in them (this system does), thus scsi_id takes the '--replace-whitespace' flag.
5.) xenial 'multipath -r' renders and expects that /etc/multipath/bindings has whitespace removed (scsi_id with --replace-whitelisted)
6.) trusty 'multipath -r' renders and expects that /etc/multipath/bindings has whitespace present (scsi_id without --replace-whitelisted)

Two last things
a.) one thing that might have to be fixed in curtin is that we only generate for the root device and let multipath handle the others at first boot. We've solved bug 1429327 for the root device, but do not do that for others. We can solve this by using /dev/mapper/mpath-X in /etc/fstab for each volume we reference.
b.) it seems that 5 and 6 above is an upgrade problem unless something is going to translate that file on upgrade from trusty to xenial.