[dm-devel] multipath-tools 0.7.4 failure to remove device

[Martin Wilck]

On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> > > 
> > > It was your commit that made it imply -n that caused the test
> > > failure
> > > :)
> > > I understand your position on that, but reverted it for Ubuntu,
> > > because,
> > > while it might be somewhat broken, it's at least the same level
> > > of
> > > broken
> > > as before.
> > 
> > I'd like to understand that better. Why would this break boot?
> 
> Ah sorry for the confusion. It did not break boot. Having finding
> disabled would have "broken" boot. The problem I was talking about
> was that with finding enabled, no dm devices were generated, which
> it turned out, was not entirely true - you had to run multipath
> manually (due to your find implies -n commit). 
> 
> It seems to me that this would cause more issues in practice than
> just keeping the slightly race-y combination enabled. It's something
> to revisit after the ubuntu lts when then people have some time to
> adjust to that change.

I wouldn't call it "slightly race-y". With find_multipaths "on" and
"ignore_wwids" "off", "multipath -u" classifies every device as a
multipath device. So SYSTEMD_READY=0 will be set on each device. But
multipathd, which is responsible for actually setting up the map, will
honor "find_multipaths", and will not set up a map for a device it
finds only a single path for. So the device never appears in a state in
which systemd would be able to use it. Unless you've put in some other
magic, this is almost guaranteed to make your system unbootable in the
quite common case where people using multipath are running off a non-
multipathed local root disk.

Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)