Control: reassign -1 multipath-tools Control: found -1 0.5.0-5
Dear multipath-tools Maintainers, this is bug, which is a clone of #775778, is essentially the same problem as was discussed in #775778: the ordering of the multipath-tools init script after after $remote_fs (see Should-Start line in LSB headers) causes an ordering problem, because systemd will wait for all _netdev filesystems in /etc/fstab before the equivalent of $remote_fs is reached. This means that systemd will wait for the /dev/mapper/... devices related to multipath to appear during boot, but at a point where remote-fs.target (systemd's mapping of $remote_fs) is not yet reached. This will lead to a 90s timeout (systemd's default timeout when waiting for devices), only then will systemd continue booting. Please see the original bug report for details w.r.t. open-iscsi; the same reasoning applies to multipath-tools. The same fix that was implemented for open-iscsi in principle also applies for multipath-tools, i.e. make sure that for systemd systems the unit is ordered before remote-fs-pre.target. I don't use multipath-tools myself, but I'll be able to prepare a patch that fixes this on a minimal level tomorrow, you'll just have to test it yourself. Christian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
