Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A "Linux debian 3.2.0-0.bpo.3-amd64 #1 SMP Thu Aug 23 07:41:30 UTC 2012 x86_64 GNU/Linux" system has at least 5 SCSI hosts:

root@debian:~# ls /sys/class/scsi_host
host0  host1  host2  host3  host4

root@debian:~# cat /sys/class/scsi_host/host0/proc_name  
root@debian:~# cat /sys/class/scsi_host/host1/proc_name
root@debian:~# cat /sys/class/scsi_host/host2/proc_name
root@debian:~# cat /sys/class/scsi_host/host3/proc_name
root@debian:~# cat /sys/class/scsi_host/host4/proc_name

The mpt2sas SCSI bus has 32 drives attached. On boot (after a reboot) the drives are mostly in standby state (spin down). This causes each drive to spin up in a sequential order. The spin up time of a typical drive is 8 till 9 seconds. As a result the boot after a reboot will take almost 5 minutes.

Having configured to the kernel to scan the scsi bus asynchrone GRUB_CMDLINE_LINUX="scsi_mod.scan=async" doesn't improve boot after reboot time. And setting scsi_mod.scan=none makes the system to not boot at all.

The final goal is to boot via USB, which is another scsi_host:

# cat /sys/class/scsi_host/host5/proc_name

How can I configure this system to exclude mpt2sas or (mpt2sas and ata_piix) bus from spinning up all drives during boot after reboot?

share|improve this question
Did you consider trying to add the mpt2sas module to the modules blacklist (assuming that it is compiled as a module), then modprobe it from /etc/rc.local? That should at least delay the probing until everything else has started, at the obvious expense of those drives not being available during the boot sequence. Depending on your needs (and assuming nothing critical is on that bus) this may be an acceptable tradeoff. – Michael Kjörling Nov 15 '12 at 19:31
There is a file /lib/modules/3.2.0-0.bpo.3-amd64/kernel/drivers/scsi/mpt2sas/mpt2sas.koa, so this looks like it is compiled as a module. After blacklisting using echo 'blacklist mpt2sas' >> /etc/modprobe.d/mpt2sas.conf the drive do still spin up during boot. Am I not blacklisting correctly or isn't mpt2sas a module? – Pro Backup Nov 15 '12 at 19:43
@ProBackup you probably need to run update-initramfs -u after creating that file. – derobert Nov 15 '12 at 19:47
@derobert Indeed after update-initramfs -u and reboot the drives on the mpt2sas bus are no longer detected during boot. – Pro Backup Nov 15 '12 at 20:15
@MichaelKjörling When writing your comment as an answer, I will accept it. – Pro Backup Nov 15 '12 at 20:30
up vote 2 down vote accepted

Since the large array is on a controller of a separate type (make and model, or rather: chipset), and nothing on it is needed for the system boot process, you can work around this by forcing a delayed controller initialization. The easiest way to do that is to simply blacklist the kernel module that does the kernel initialization, then load it manually very late in the boot process.

NOTE: It is extremely important that this is done only with controllers that hold nothing that is needed for the system to boot properly. Otherwise, you will find yourself with a boot failure - anything from services failing to start or reading/writing files in the wrong place, to an outright kernel panic. Keep this in mind before implementing a scheme like this.

First, find out which kernel module handles the controller in question. A quick Google search based on the information provided in the question says this likely indeed is the mpt2sas module. Second, make sure that the code is actually compiled as a module; something like find "/lib/modules/$(uname -r)" -name 'mpt2sas*' -print will do nicely. (Yes, I know that -print is the default, but I like to be explicit...) Verify its status as a loaded module using lsmod | grep mpt2sas.

Then, add the module to the modules blacklist file. You can either add it to /etc/modprobe.d/blacklist.conf, or a separate configuration file such as /etc/modprobe.d/mpt2sas.conf. Just add the following line to such a file.

blacklist mpt2sas

This will disable automatic loading of the module in question. We are going to take advantage of the fact that it can still be loaded manually using e.g. modprobe - where "manually" can mean "from a script".

Open /etc/rc.local (which is executed after all other rc scripts) in an editor, and add the following lines somewhere in it:

modprobe mpt2sas
mount -a

You probably want to put this late in the file, but obviously before any exit or similar directives. The mount -a may or may not be needed depending on whether the file systems are actually to be mounted on boot and whether they are mounted automatically when they are found by the kernel disk partition probing. You can try without it first, if you want to and feel safe that you can gain access to the system if it doesn't work. If you need anything special to start up RAID or somesuch, that goes between the modprobe and mount. If any specific services need the large array to be available, you can create a separate rc script to start the array and specify that it should run before any such services are started. You can make it execute in the background by wrapping it in a subshell with a syntax like ( commands ) &, but that may or may not have any noticable effect on the result because partition probing is done in the kernel. You may be able to use hdparm to spin down the drives after the partition has been mounted, if they are only rarely accessed. In short, this is the part you may want to customize for your particular needs.

Then, update your initramfs by executing update-initramfs -u as root.

If nothing failed, you should now be able to reboot your system and enjoy the benefits of delayed disk spin-up and partition probing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.