[Bug 1430074] Re: d-i multipath disk-partition separator overhaul

Mauricio Faria de Oliveira mauricfo at linux.vnet.ibm.com
Wed Mar 11 11:14:53 UTC 2015


@vorlon

I'm looking at that bug; will post soon.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1430074

Title:
  d-i multipath disk-partition separator overhaul

Status in debian-installer package in Ubuntu:
  New

Bug description:
  This bug is an umbrella for a number of bugs in the debian-installer with common 
  root cause: the different disk-partition separator used for multipath partition
  block devices by parted_server (libparted) and some components of the installer.

  The specific problems will be presented shortly. They are summarized in this bug
  rather than reported individually because the solution is common, and involves 3
  source packages; so it's simple to glance over the bug (.. big) picture, problem
  and solution at once, and likewise for reviewing the patches.

  The demonstration and steps to reproduce are contained in an attached text file,
  for being an install session with descriptive steps and comments.  It's somewhat
  long, but very easy to follow.  The solution testing is also attached in a text
  file (and is shorter).


  Overall problem:
  ---------------

  The installer (i.e., its components; e.g., partman-*, grub-installer) makes use
  of the 'parted_server' program (which relies on 'libparted') to handle disk and
  partition devices.  It's used to list disks and their partitions, and to modify
  partitions in the disks (e.g., create, resize, flag, delete).

  Whenever parted_server (libparted) produces a list of partitions in a multipath
  disk (for consumption by installer components), or creates such  (i.e., a block
  device in /dev/mapper for a partition in a multipath disk), the following disk-
  parition separator is used: 'p'. This is hard-coded in libparted (arch/linux.c).

  For example: /dev/mapper/mpath0p1

  The problems arise on some installer components which have code for handling an
  installation on multipath disks/partitions (e.g., partition the multipath disks,
  format the partitions in multipath disks, install the bootloader in one of them).

  Those components assume the multipath disk-partition separator is '-part'. This
  is hard-coded in them.

  For example: /dev/mapper/mpath0-part1


  Overall solution:
  ----------------

  After the evaluation of a few solution alternatives, this one looked
  like right.

  It's short, simple, and non-invasive -- all changes are delivered in multipath-
  specific functions or conditional blocks, except for 2 ppc64el-specific changes,
  that actually are required to improve grub-installer for multipath on ppc64el).

  Fundamentally, stick to 'p' as multipath disk-partition separator.

  Reasons:
  - First of all: no impact nor change to non-multipath stuff.
  - Second: multipath partitions listed by parted_server exist in /dev/mapper,
            with the listed block device name; consistently:
            - including those created/modified by parted_server, 
            - and those existing/non-modified -- untouched by parted_server.


  Specific problems:
  -----------------

  In order of appearance (in the installer). See the attached file with the steps
  to reproduce/demonstration.

  P.S.: some problems reported are not related to the disk-partition separator,
        but are minor errors related to the multipath support in the installer
        (still contained in multipath-specific functions or conditional blocks)
        and have fixes provided in the best interest of the debian-installer.

  
  Problem #1:  The underlying devices of multipath devices are listed in the
  ----------   partitioning dialogs.
              
  The underlying devices cannot be accessed, because the device-mapper locks them
  with exclusive access.

  There's already code to do this, but it's broken due to a wrong grep expression,
  that checks whether a device is an underlying device of a multipath devices.

  Fixed in partman-base:
  	- init.d/parted: part_of_multipath():
  	  Update grep expression for more recent output of 'multipath -l'.

  
  Problem #2:  Human-description of a multipath device is not a single device string;
  ----------   it actually contains multiple strings from the same device name/WWID.

  Some multipath devices' WWID have more than only hexadecimal characters; this
  breaks a sed substitution expression, thus leaving spaces in its output, which
  are not correctly handled.

  Fixed in partman-base:
  	- lib/base.sh: humandev():
  	  Accept spaces/non-hex-only characters in multipath WWID.

  
  Problem #3:  Non-existing LVM VGs/LVs shown for existing multipath partitions
  ----------

  If multipath partitions are not correctly identified (because of the multipath
  disk-partition separator), they end up considered LVM VGs/LVs in the dialog for
  listing/choosing partitions.

  Fixed in partman-base:
  	- lib/base.sh: is_multipath_part():
  	  Use 'p' (not '-part') as multipath disk-partition separator.

  
  Problem #4:  Failure when formatting existing multipath partitions (i.e.,
  ----------   not created/modified by the partitioner via parted_server)

  If multipath partitions are not created/modified with the partitioner, they are
  not created in /dev/mapper by parted_server/libparted  (note: this would create
  them with the 'p' disk-partition separator).

  In that case, the multipath partitions end up created in /dev/mapper by kpartx
  with the '-part' disk-partition separator in a commit.d/ hook.

  Afterwards, in the format.d/ hooks, parted_server lists the partitions in a
  multipath disk with the 'p' disk-partition separator, which leads to an error,
  because (as described) /dev/mapper/mpathX*p*Y doesn't exist, but mpathX*-part*Y.

  Fixed in partman-multipath:
  	- commit.d/partition_multipath:
  	  Use 'p' (not '-part') as multipath disk-partition separator.
  	  (during d-i.)

  
  Problem #5:  Incorrect multipath partition device names in target's /etc/fstab
  ----------

  In the finish.d/ hooks, the device names that are inserted in /target/etc/fstab
  come from partition listings by parted_server -- therefore, with the 'p' disk-
  partition separator.

  This is wrong for the target system, because it has kpartx udev rules shipped
  with the multipath-tools package (and carried to initramfs by multipath-tools-boot),
  and the kpartx udev rules specify the '-part' disk-partition separator.

  So, this is one place where we actually have to change from 'p' to
  '-part'.

  It is done immediately after the hook/script that inserts /dev/mapper devices
  in the /target/etc/fstab file, using a sed expression.

  Fixed in partman-multipath:
  	- (new file) finish.d/fstab_hd_entries_multipath:
  	  Use '-part' (not 'p') as multipath disk-partition separator.
  	  (for the target.)

  
  Problem #6:  PReP partition-flag is lost on multipath disk every 2 changes to
  ----------   its partition table

  (this should be automatically fixed with problem #1.)

  When a multipath disk is first partitioned, and a multipath partition is defined
  as PReP boot partition, the partition has the flag 'prep' set.

  The flag propagates to the underlying device, obviously (multipath is just multi-
  ple paths to the a device).

  The next time that disk is partitioned, that occurs normally for the multipath
  disk; however, the partitioner notices that the underlying device now has a 
  partition with the 'prep' flag set, and because it was not requested on the
  underlying device (only on the multipath disk), the partitioner resets the flag.

  The flag reset in the underlying device also propagates to the
  multipath device.

  Now there's no partition w/ the PReP flag anymore.

  This is a problem for grub-installer on ppc64el, because it currently uses the
  'prep-bootdev' program, which finds a PReP partition using that flag/libparted.

  Fixed in problem #1.

  
  Problem #7:  GRUB is installed on an underlying device, not the multipath disk.
  ----------

  The grub-installer script fails to identify the partition with boot filesystem
  as a multipath partition because it expects the '-part' disk-partition separator.

  Therefore, an underlying disk/partition is selected.  Although it is working on
  the test scenario, it is certainly not the right approach with multipath, and
  should be fixed.

  This is fixed differently for non-ppc64el and ppc64el architectures, because
  ppc64el currently uses the 'prep-bootdev' program to find a PReP partition.

  Fixed in grub-installer for non-ppc64el:
  	- grub-installer:
  	  Use 'p' (not '-part') as multipath disk-partition separator.

  Fixed in grub-installer for ppc64el:
  	- grub-installer:
  	  [ppc64el] bootdev/wipe_bootdev: prefer PReP partition in the
  	  same disk as the boot file system partition ($disc_offered).
  	- prep-bootdev:
  	  add '-l' option to list all PReP partitions.


  
  Steps to Reproduce
  ------------------

  See attachment (reproducing_mpathsep.txt)

  
  Solution
  --------

  See attachments:
  - partman-base_mpathsep.debdiff
  - partman-multipath_mpathsep.debdiff
  - grub-installer_mpathsep.debdiff

  
  Solution Testing (ppc64el & amd64)
  ----------------------------------

  See attachment (testing_mpathsep.txt)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1430074/+subscriptions



More information about the Ubuntu-sponsors mailing list