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@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
