[Bug 1432062] Re: Ship the default /etc/multipath.conf on multipath-tools-boot (for user_friendly_names)

Mauricio Faria de Oliveira mauricfo at linux.vnet.ibm.com
Fri Mar 13 22:20:25 UTC 2015


BTW, I have prototype patches to fix the spacing issue in udev rules
(pathes for kpartx.rules, multipath.rules, and kpartx_id IIRC)

But I guess that at this point of the schedule it'd be safer to go w/
shipping a default thing which could have been installed, rather than
changing stuff at the udev rules level.

The problem seems to emerge from the general dm.rules, which on recent
kernels will set DM_NAME as the mangled name which is obtained from
sysfs/.../dm/name, but some Debian-specific thing related to dmsetup not
exporting variables correctly will re-set DM_NAME to a non-mangled
name.. this is leading to problem in the rest of that rules file.. Also,
kpartx_id IIRC-2 gets a non-mangled name, in variable dmname IIRC-3.)

I can provide those patches if you're interested in taking a look.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1432062

Title:
  Ship the default /etc/multipath.conf on multipath-tools-boot (for
  user_friendly_names)

Status in multipath-tools package in Ubuntu:
  New

Bug description:
  If a system is not installed w/ multipath support (i.e., no disk-detect/multipath/enable=true), the /etc/multipath.conf file is not installed.
  If an user later installs multipath-tools-boot, it will enable the udev rules for multipath support.
  Those rules don't handle disk devices w/ spaces on their names/uuids/models very well.. 

  That's because of udev's SYMLINK command using spaces to separate
  multiple links, and the kernel sysfs/dm informing \x20 instead, which
  is not correctly interpreted by some commands, resulting in file not
  found errors, for example.

  Thus, the system fails to boot.

  There's no problem, however, if user_friendly_names is enabled in
  multipath.conf (which is enabled in the default multipath.conf from
  the installer, if it has multipath enabled).

  Notice it's an acceptable case to install w/out multipath support, and
  enable it later for booting.

  Disk devices w/ spaces in naming is not common over SAN/storage systems, but that happens often for conventional disks; for example:
  - IBM IPR  ( IBM     IPR-0   5DB6F40000000080 )
  - IBM VDASD ( AIX     VDASD           00c96f0700004c000000014bb8e713f0.14 ) 
  - QEMU HARDDISK ( QEMU QEMU HARDDISK <serial> )

  So, please, is it possible to ship the default multipath.conf (e.g.,
  from installer) w/ multipath-tools-boot?

  For users not to their systems failing to boot after installing
  multipath-tools-boot manually, after a non-multipath install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1432062/+subscriptions



More information about the foundations-bugs mailing list