[Bug 1546606] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From mauricfo at br.ibm.com 2016-02-18 13:25 EDT-------
@mathieu-tl,

(In reply to comment #32)
> I'm attaching a patch for multipath-tools as well,
> so to avoid any delays and more SCSI errors during boot time.
>
> Tested on another system, attached via FC to DS4800 storage (which uses
> RDAC), and with IPR disks (which uses ALUA).

Here's the boot time verification:

<...>
Loading, please wait...
Begin: Loading multipath modules ... [    2.256763] device-mapper: multipath: version 1.10.0 loaded
Success: loaded module dm-multipath.
done.
Begin: Loading multipath hardware handlers ... [    2.259401] alua: device handler registered
Success: loaded module scsi_dh_alua.
[    2.261424] rdac: device handler registered
Success: loaded module scsi_dh_rdac.
done.
starting version 229
<...>

$ lsmod | grep scsi
scsi_transport_fc      71759  1 lpfc
scsi_dh_rdac            9656  32
scsi_dh_alua            9962  16

------- Comment From mauricfo at br.ibm.com 2016-02-18 13:29 EDT-------
*** Bug 125894 has been marked as a duplicate of this bug. ***

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to hw-detect in Ubuntu.
https://bugs.launchpad.net/bugs/1546606

Title:
  Unable to install Ubuntu 16.04 on Tuleta with multipath setup

Status in hw-detect package in Ubuntu:
  In Progress

Bug description:
  ---Problem Description---
  Unable to succeed in installing  Ubuntu 16.04 on Tuleta with multipath setup; installation hung at scanning disks
   
  == Comment: #11 - Kevin W. Rudd - 2016-02-05 13:13:11 ==

  It looks like the issue in this case involves an RDAC based storage
  controller and I/O errors on the ghost paths.

  == Comment: #23 - Mauricio Faria De Oliveira - 2016-02-17 07:48:23 ==
  Hi Canonical,

  This patch resolves this problem. It's been tested on 16.04.
  Please consider it for uploading. 

  @taco-screen-team, I believe @mathieu-tl would be assigned to this
  one, it it helps.

  
  Testing udeb package:

  	~ # wget http://ausgsa.ibm.com/~mauricfo/public/bugs/bz136625/v1/disk-detect_1.114ubuntu1scsidh1_all.udeb
  	~ # udpkg -i disk-detect_1.114ubuntu1scsidh1_all.udeb 

          Detect disks happened.

  It is working correctly.

  1) The SCSI DH modules are correctly loaded and attached (see
  references count) to SCSI disk.

  
  	~ # lsmod | grep scsi
  	scsi_transport_fc      71759  1 lpfc
  	scsi_dh_alua            9962  16
  	scsi_dh_hp_sw           5252  0
  	scsi_dh_emc             9486  0
  	scsi_dh_rdac            9656  32

  2) The 'Scanning disks' dialog show I/O error dialogs rather than a
  silent, extremely long delay.

          [!] Partition disks

          Error fsyncing/closing /dev/sdag: Input/output error

          Warning!

  	Retry
  	Ignore

          <Go Back>

  == Comment: #26 - Mauricio Faria De Oliveira <mauricfo at br.ibm.com> - 2016-02-17 09:20:28 ==
  Quick summary.

  The long delays are caused due to dmraid scanning the RDAC unowned
  paths to the storage unit (seen in multipath -l as 'ghost' paths).

  They happen in 2 points: during hw-detect/disk-detect and
  partman/init.d/30parted (Scanning disks).

  If you have multipath enabled in the installation, 
  the 2nd delay doesn't happen as the individual SCSI disks (/dev/sdX) are not considered by partman, 
  but the 1st delay does occur *anyway*, as /bin/disk-detect does call dmraid to scan available devices.

  So, the fix is beneficial for both scenarios (multipath enabled and
  disabled; e.g., user forgot to/didn't know he should enable it).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1546606/+subscriptions