<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Linux boot 40 minute stall whilst starting multipath in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540674#M39050</link>
    <description>This part of the boot procedure is controlled by /etc/rc.d/rc.sysinit.&lt;BR /&gt;&lt;BR /&gt;After the root filesystem is successfully mounted in read-write mode, the system runs these commands (for simplicity, I've omitted all if/then conditionals and followed the most likely execution path in this case):&lt;BR /&gt;&lt;BR /&gt;modprobe dm-mod&lt;BR /&gt;restorecon /dev/mapper/control&lt;BR /&gt;modprobe dm-multipath&lt;BR /&gt;/sbin/multipath-static -v 0&lt;BR /&gt;/sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"&lt;BR /&gt;&lt;BR /&gt;modprobe dm-mirror&lt;BR /&gt;/sbin/dmraid -i -a y&lt;BR /&gt;&lt;BR /&gt;"No RAID disks" apparently comes from /sbin/dmraid. So the delay must be caused by one of the commands before it.&lt;BR /&gt;&lt;BR /&gt;The modprobe and restorecon commands should be pretty benign: they operate on the system disk and memory only. The remaining three commands all do some disk probing, so might cause a delay if something does not work as intended:&lt;BR /&gt;&lt;BR /&gt;/sbin/multipath-static -v 0&lt;BR /&gt;/sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"&lt;BR /&gt;&lt;BR /&gt;/sbin/dmraid -i -a y&lt;BR /&gt;&lt;BR /&gt;My suggestion:&lt;BR /&gt;None of these commands should be harmful to execute. Try running them manually, one at a time, to see which one takes a lot of time.&lt;BR /&gt;&lt;BR /&gt;If the problem is caused by dmraid, "chmod a-x /sbin/dmraid" would cause the script to skip the dmraid commands. But that would be just a work-around.&lt;BR /&gt;&lt;BR /&gt;If possible, try temporarily unpresenting the SAN tapes and see if it makes any difference. The dm-multipath tools have been developed for disks only; it might be possible that they don't (yet) know the difference between a SAN disk and a SAN tape drive.&lt;BR /&gt;&lt;BR /&gt;MK</description>
    <pubDate>Fri, 27 Nov 2009 12:19:43 GMT</pubDate>
    <dc:creator>Matti_Kurkela</dc:creator>
    <dc:date>2009-11-27T12:19:43Z</dc:date>
    <item>
      <title>Linux boot 40 minute stall whilst starting multipath</title>
      <link>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540673#M39049</link>
      <description>I have recently attached an EVA4400 to my test SAN and configured my Linux RH 4 Update 8 server accordingly to allow it to use an EVA presented Lun.&lt;BR /&gt;&lt;BR /&gt;Initial boot saw the server find 4 new disk devices; that's one per path to the LUN on the EVA.&lt;BR /&gt;&lt;BR /&gt;I then configured multipath and all seemed fine UNTIL the next reboot when I now find the server stalls during reboot just after checking the root filesystem:&lt;BR /&gt;&lt;BR /&gt;26-Nov-2009 12:50:38  Checking root filesystem&lt;BR /&gt;26-Nov-2009 12:50:38  [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/vg0/lv0 &lt;BR /&gt;26-Nov-2009 12:50:39  /dev/vg0/lv0: clean, 9479/524288 files, 83820/1048576 blocks&lt;BR /&gt;26-Nov-2009 12:50:39  [  OK  ]&lt;BR /&gt;26-Nov-2009 12:50:39  Remounting root filesystem in read-write mode:  [  OK  ]&lt;BR /&gt;26-Nov-2009 13:31:36  No RAID disks&lt;BR /&gt;26-Nov-2009 13:31:37  Setting up Logical Volume Management: [  OK  ]&lt;BR /&gt;&lt;BR /&gt;Note the 40 minute gap before the "No RAID disks" line.  Then the boot sequence continues on; finds and mounts up my EVA LUN and all is good.&lt;BR /&gt;&lt;BR /&gt;Anyone got any pointers?&lt;BR /&gt;&lt;BR /&gt;This server is also zoned to be able to use some SAN based tapes via the same HBA as well.  It's a test lab server.&lt;BR /&gt;&lt;BR /&gt;Server is fully patched via up2date from my RH Sattelite server.&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;BR /&gt;Malcolm &lt;BR /&gt;</description>
      <pubDate>Fri, 27 Nov 2009 02:00:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540673#M39049</guid>
      <dc:creator>Malcolm Wade</dc:creator>
      <dc:date>2009-11-27T02:00:44Z</dc:date>
    </item>
    <item>
      <title>Re: Linux boot 40 minute stall whilst starting multipath</title>
      <link>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540674#M39050</link>
      <description>This part of the boot procedure is controlled by /etc/rc.d/rc.sysinit.&lt;BR /&gt;&lt;BR /&gt;After the root filesystem is successfully mounted in read-write mode, the system runs these commands (for simplicity, I've omitted all if/then conditionals and followed the most likely execution path in this case):&lt;BR /&gt;&lt;BR /&gt;modprobe dm-mod&lt;BR /&gt;restorecon /dev/mapper/control&lt;BR /&gt;modprobe dm-multipath&lt;BR /&gt;/sbin/multipath-static -v 0&lt;BR /&gt;/sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"&lt;BR /&gt;&lt;BR /&gt;modprobe dm-mirror&lt;BR /&gt;/sbin/dmraid -i -a y&lt;BR /&gt;&lt;BR /&gt;"No RAID disks" apparently comes from /sbin/dmraid. So the delay must be caused by one of the commands before it.&lt;BR /&gt;&lt;BR /&gt;The modprobe and restorecon commands should be pretty benign: they operate on the system disk and memory only. The remaining three commands all do some disk probing, so might cause a delay if something does not work as intended:&lt;BR /&gt;&lt;BR /&gt;/sbin/multipath-static -v 0&lt;BR /&gt;/sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"&lt;BR /&gt;&lt;BR /&gt;/sbin/dmraid -i -a y&lt;BR /&gt;&lt;BR /&gt;My suggestion:&lt;BR /&gt;None of these commands should be harmful to execute. Try running them manually, one at a time, to see which one takes a lot of time.&lt;BR /&gt;&lt;BR /&gt;If the problem is caused by dmraid, "chmod a-x /sbin/dmraid" would cause the script to skip the dmraid commands. But that would be just a work-around.&lt;BR /&gt;&lt;BR /&gt;If possible, try temporarily unpresenting the SAN tapes and see if it makes any difference. The dm-multipath tools have been developed for disks only; it might be possible that they don't (yet) know the difference between a SAN disk and a SAN tape drive.&lt;BR /&gt;&lt;BR /&gt;MK</description>
      <pubDate>Fri, 27 Nov 2009 12:19:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540674#M39050</guid>
      <dc:creator>Matti_Kurkela</dc:creator>
      <dc:date>2009-11-27T12:19:43Z</dc:date>
    </item>
    <item>
      <title>Re: Linux boot 40 minute stall whilst starting multipath</title>
      <link>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540675#M39051</link>
      <description>Matti,&lt;BR /&gt;&lt;BR /&gt;Thanks for this great info!&lt;BR /&gt;&lt;BR /&gt;I narrowed the issue down to dmraid.  For the moment (until I have more time) I have simply denied exec as you sugested and the boot cycle proceeds as per normal.&lt;BR /&gt;&lt;BR /&gt;I'll look a bit further later in the week.&lt;BR /&gt;&lt;BR /&gt;Thanks again,&lt;BR /&gt;Malcolm</description>
      <pubDate>Mon, 30 Nov 2009 05:31:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/linux-boot-40-minute-stall-whilst-starting-multipath/m-p/4540675#M39051</guid>
      <dc:creator>Malcolm Wade</dc:creator>
      <dc:date>2009-11-30T05:31:20Z</dc:date>
    </item>
  </channel>
</rss>

