[Bug 1538775] Re: multipath-tools-boot relies on scsi_wait_scan module, fails multipath setup
Haven't had a chance to raise it yet (having to use the environment for something else atm so I wouldn't be able to capture logs), though plan to do it next week once the environment is free. Some thoughts around potential workarounds/fixes: - Boot option (similar to rootwait/rootdelay) to impose a sleep period (this way its optional and flexible) - Package to go alongside multipath-boot that adds a new script (which in turn waits), and executes before multipathd - Getting udev to force a scan of the SCSI bus and wait for it to finish (i.e. indicate there is nothing new) - Figuring out why the qla2xxx driver doesn't seem to like me... -- You received this bug notification because you are a member of Ubuntu Server Team, 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1538775/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1526984] Re: ISST-LTE: root mpath device unavailable after installation
Mathieu, As noted in LP:1538775, version 0.4.9-3ubuntu7.8 still isn't resolving the issue for me, as while my system does start (im not dropping to a rescue shell), the multipath daemon seems to be executed prior to the disks being discovered/udev starting and so it boots using sda for root instead of mpath. Running 'multipath -v5' post-boot shows that it wants to reconfigure pathing but cannot as the disks are in-use (understandably). I've attached the dmesg log which shows when multipathd starts, the disks are detected, then udev starts. ** Attachment added: "dmesg" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1526984/+attachment/4564421/+files/dmesg -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1526984 Title: ISST-LTE: root mpath device unavailable after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1526984/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1538775] Re: multipath-tools-boot relies on scsi_wait_scan module, fails multipath setup
Brian, Package tested (0.4.9-3ubuntu7.8) and can confirm that it does resolve the problem around loading the missing module. It doesn't however fix the issue of the multipath root device working (as my system is back to sda rather than mpath). As per Matthiew's comment (4) I will update LP:1526984 as that is a closer match to the current symptoms (though its not a complete match). ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1538775/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1538775] Re: multipath-tools-boot relies on scsi_wait_scan module, fails multipath setup
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 Server Team, 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1538775/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1538775] [NEW] multipath-tools-boot relies on scsi_wait_scan module, fails multipath setup
Public bug reported:
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.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
** Project changed: saucy-backports => multipath-tools (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1538775/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
