[Bug 1538775] Re: multipath-tools-boot relies on scsi_wait_scan module, fails multipath setup
Stuart Hopkins
stu at lifeofstu.com
Mon Feb 1 15:02:25 UTC 2016
Just to be clear, it isn't the error message that is a problem when
attempting to boot, its that the system will not boot with multipath
support because the multipath discovery in the initrd is performed
before the SCSI devices are available. Removing the current code
referring to the removed module won't actually fix the issue as the
discovery will still take place before the qla2xxx driver has had a
chance to discover the LUN's, thus the root fs will be mounted on
/dev/sda instead of /dev/mapper/mpath0, and cannot be changed later (as
the LUN is currently active).
This is why I had to add in a sleep statement so that the multipath scan
takes place after the devices have been discovered. Not a clean solution
at all, but I am unsure as to what replaced the scsi_wait_scan given the
async changes.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1538775
Title:
multipath-tools-boot relies on scsi_wait_scan module, fails multipath
setup
Status in multipath-tools package in Ubuntu:
Fix Released
Status in multipath-tools source package in Trusty:
In Progress
Bug description:
[Impact]
Users of multipath may see an error message on every boot (when in verbose mode) about the scsi_wait_scan module being unavailable.
[Test case]
Boot 14.04 system with multipath-tools-boot. (Multipath devices installed, and the pacakge multipath-tools-boot installed).
[Regression Potential]
None. This module has been removed for a long while; as such this has no effect aside from removing an extra error message on boot.
------
Release: Ubuntu 14.04.3 LTS
Kernel: linux-image-3.16.0-59-generic
A clean system installed fresh today (2016-01-27)
In attempting to configure a system to boot-from-SAN and enable
multipath support I ran into an issue whereby despite the multiple
paths being detected (when running the multipath command from the CLI)
the configuration wasn't being enabled at boot. After examining
/usr/share/initramfs-tools/scripts/local-top/multipath I found the
following:
verbose && log_begin_msg "Waiting for scsi storage"
{ rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; } >/dev/null 2>&1
verbose && log_end_msg
The problem appears to be that the scsi_wait_scan module doesn't
exist and so there is no wait before the multipath scan is performed.
I managed to observe this briefly during bootup (with the script
edited) and could see it performed the scan before sda/sdb was
discovered.
I also found a debian bug report indicating the module was removed a
while back (https://lists.debian.org/debian-
kernel/2012/05/msg00791.html).
After adding in an artificial delay for testing the multipath command
does what is expected and configures the paths accordingly. I'm not
sure what the correct approach is if the scsi_wait_scan module is
removed.
I also found that the same local-top script doesnt have the dm-round-
robin module loaded (but it is included in the initrd by the
associated hook script), however I'm not sure if that is by design. I
know I need it for my specific use-case, but don't know if it is
deliberately excluded to prevent breakage on SAN units that don't
support native round-robin.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1538775/+subscriptions
More information about the foundations-bugs
mailing list