Dear Maintainers,

the partman-multipath installer modules does not detect multipath devices
because the multipath alias names have been changed.  Also the location of
the bindings file has been changed and, therefore, correct its location in
the post-base-installer script.

Below you can find a patch that solves both problems.  Feedback is welcome.

Thanks!

Kind regards,
  Hendrik

Hi,

Hendrik Brueckner <brueckner@linux.vnet.ibm.com> (2015-12-02):
https://lists.debian.org/debian-boot/2015/05/msg00271.html

He also told me some more changes were needed when we met in Heidelberg
IIRC but I'm not certain, so I'm adding him to the loop so that he can
comment on your proposed changes.

Mraw,
KiBi.

[...]
That's spot on, it's exactly what is needed in partman-multipath.

Still, shouldn't we also copy over the wwids file from the installer onto
the target?

hw-detect needs a similar change, which I've already done at [1], and some
changes for the output of multipath -l in partman-base at [2].

[1]
http://anonscm.debian.org/cgit/d-i/hw-detect.git/commit/?h=people/cyphermox/mpath-detect
[2]
http://anonscm.debian.org/cgit/d-i/partman-base.git/log/?h=people/cyphermox/multipath5

Mathieu Trudel-Lapierre <mathieu.tl@gmail.com>
Freenode: cyphermox, Jabber: mathieu.tl@gmail.com
4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C  80D3 C7DA A946 DC95 CA5A

Hi,

Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> (2015-12-02):

OK.

I'll let Hendrik follow up on that.

OK. Unfortunately I haven't been able to spend sufficient time on d-i
lately so I'm afraid the 3 patchsets will have to wait until after the
upcoming release.

Since we have a few things to wait on (glibc), I might push the needed
bits to master so that they are ready for the next time.

Mraw,
KiBi.

Hi Cyril!

It's fine to defer them to a follw-up release.  I have continued to work on
the multipath stuff and I will provide a summary of what I think needs to be
integrated.  Briefly, there are some additional changes on top of those which
I'd like to discuss with you and the community.

Thanks a lot!

Kind regards,
  Hendrik

Hi,

Hendrik Brueckner <brueckner@linux.vnet.ibm.com> (2015-12-16):

Sorry it took so long to get back to you, but it seems I'm slowly
crawling through the few thousands unread mails on debian-boot@.

It would be nice if we could tackle multipath issues at some point,
please let me know how I can help.


KiBi.

Hi

I can confirm that the problem is not solved in stretch RC1 installer, so
it would be really nice to have the patches applied, so there is a chance
that multipath will work in stretch.

Best regards
Allan Jacobsen

In base multipath-tools packages, we've always recommended using persistent WWID
names instead of friendly names. They are unique and are always the same. The
simplest for D-I should be to just drop friendly names for multipathed devices.

Hi

I understand your point, but the multipath-tools is full of code for
friendly names, so what you are actually doing is making sure multipath
will not work with the stock debian installer, forcing people like me to
create our own install media, which i don't think is in the best interest
of debian as an organisation that want to be the universal operating system.

Best regards
Allan Jacobsen

2017-01-26 14:20 GMT+01:00 Ritesh Raj Sarraf <rrs@debian.org>:

No. That is wrong conclusion.

What I'm saying is that user_friendly_names has had issues in the past. Today,
they still have the burden of, when used, to ensure that the binding file is
propagated and remains up-to-date. Eg. initrd, cluster setups.

Device names based on wwid are unique and persistent.

What we are doing is just making a recommendation of Best Practices. Each
feature has its merits and drawbacks.

HI

OK, I do understand you point, but my problem is that I have been hired as
a cunsultant to set up PXE boot with preseed to install different linux
dists, and I can not put a wwid that I don't know into the preseed file,
but have to use the friendly name.

This works fine with ubuntu, but not with debian, because you wont apply
the patch.

For jessie I had to create 2 custom udebs, and It seems to be the same
waste of time is needed for stretch.

I really dont understand why multipath is part of the debian installer when
it is a well known fact that the disk-detect, multipath and
partman-multipath udebs can not work together.

Best regards
Allan Jacobsen

2017-01-27 9:47 GMT+01:00 Ritesh Raj Sarraf <rrs@debian.org>:

Well. YOu should be able to.. WWID are unique. Both the target and the initiator
report the same.

:-)

That is not my package. Debian Installer team maintains them. I'm just
mentioning my view as the maintainer of multipath-tools package.

You probably know more about this than most people, though. Is there
any downside to accepting the patch?

Hello Steve,

This patch is a very simple one, just changing multipath friendly names from
mpath[0-9] to mpath[a-z]. And another change is the change in file path for the
bindings file.
For inclusion of this patch, it looks clean to me.

But I'm not sure if this patch alone can enable multipathing support in the
Debian Installer. Cyril and Mathieu have mentioned in this bug report that more
work is needed to get it working.

I don't think D-I has ever, before, had multipathing support. So if we were to
add it, I'd recommend we keep it inline with the standard settings.

I just now, again, checked the defaults in multipath, and user_friendly_name is
set to off, by default. So, if we are using friendly names in D-I, then we'll
have 2 files to take care of, multipath.conf and bindings file.

Dear Maintainer,

This issue remains a blocker for multipath installations in Debian 12.
In some
experimentation on my end, the proposed patchset works fine and resolves the
issue. I would advocate for extending the regex to include a-z instead of
replacing the 0-9 detection so we retain backwards compatibility, but at its
core it works fine.

partman does detect any partitions on the multipath device as LVM LVs,
though,
but that's likely an issue in partman's LVM code and not here. If
there's a way
to explicitly tag a device as ignored or filtered out, though, that
might be
a workable solution here in partman-multipath.

The problem with the bindings file is technically a separate problem,
too, and
the path to the file can actually be detected at runtime using
"multipath -t",
grepping for the "bindings_file" parameter. I'd suggest we split this
issue up
into two reports and handle that separately.

I've got patches prepped for both cases if desired.

Finally, even with this patchset, multipath support is currently broken
because
of missing udev rules in dmsetup-udeb, multipath-udeb and kpartx-udeb.