SUSE Support

Here When You Need Us

Troubleshooting SCSI (LUN) scanning issues

This document (3955167) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 10
SUSE Linux Enterprise Server 9
SUSE Linux Enterprise Server 8


SCSI storage or SAN (e.g. Fibre Channel based)

Sample symptoms:
  • Cannot see more than 7 SCSI Devices
  • Cannot see more than 7 LUNs
  • Some LUNs are not detected


Use kernel parameters to change the way SCSI devices are scanned for.

Additional Information


On a Linux system SCSI devices are usually detected automatically upon boot or once the respective driver module for the SCSI controller is loaded. Under certain circumstances this detection might fail or not be completely correct.

Sanity check

A SCSI controller or Fibre Channel HBA typically offers the possibility of scanning for storage/LUNs from its BIOS. In particular for Fibre Channel SANs, where factors like complex cabling, LUN masking and zoning can come into play, it's a good sanity check to first use this facility to check that the storage is seen at this level. If storage is not visible through the controller's BIOS, it will not be seen by the operating system either and the problem lies outside the operating system's control.

SCSI scanning flags example

Boot with
scsi_mod.default_dev_flags=0x240 (SLES9 and newer)
scsi_largelun=1 scsi_sparselun=1 (SLES8)
to scan for LUNs larger than 7 on a SCSI-2 device and to scan without assuming LUNs are consecutive.

SCSI scanning flags (not for SLES8)

The parameters that influence the SCSI scanning behaviour are combined in a single parameter, scsi_mod.default_dev_flags. This parameter can be passed to the kernel through the kernel command line, or it can be built into the initial RAM disk (initrd) through a line
options scsi_mod default_dev_flags=value
in /etc/modprobe.conf.local

The value for
scsi_mod.default_dev_flags is the sum of the applicable individual flag values (as detailed below).

SCSI scanning flags (SLES8 only)

SLES8 uses an older kernel and has individual parameters for the various flags which can be passed on the kernel command line or which can be added to /etc/modules.conf to be built into the initrd.

Flag: Handle sparse LUN numbering
Flag value: 0x040
(SLES8: scsi_sparselun=1)

By default, LUNs are scanned sequentially and scanning stops when a LUN has been reported not to exist. (or when max_luns is reached). This flag should be used when the LUN numbering is sparse, i.e. non-consecutive. With it, scanning continues until max_luns is reached, which may increase the scan time but makes sure all LUNs of a target are scanned for.

Flag: Use REPORT_LUNS command
Flag value: 0x20000
(SLES8: scsi_reportlun2=1)

Instruct the kernel to try the REPORT_LUNS command even for SCSI-2 devices in case the SCSI host controller (HBA) does support more than 8 LUNs (the maximum for SCSI-2 devices according to the SCSI standards). This option is safe to use as the broken USB devices that lock up on REPORT_LUNS are on the USB controller which does not support more than 8 LUNs.

Flag: Scan for large LUNs
Flag value: 0x200
(SLES8: scsi_largelun=1)

Theoretically, only SCSI-3 devices should have LUNs larger than 7, but in practice there are some devices which report themselves as supporting SCSI version 2 but which have LUNs larger than 7. This parameter forces scanning for LUNs larger than 7 on non-SCSI-3 devices.

Flag: switch off the use of REPORT_LUN
Flag value: 0x40000
(SLES8: scsi_noreportlun=1)

For SCSI-3 devices the REPORT_LUN command is used to avoid the need for a serial scan and thus to avoid problems with non-consecutive LUNs. This can be switched off with this parameter, which is needed in case the LUN mapping of the host adapter and the Linux are different. For the zfcp adapter, REPORT_LUN is not used.

More specific targetting of devices

scsi_mod.default_dev_flags sets the scanning options for all devices. When this causes undesired side effects with other devices, a variant can be applied to a specific device only.

The syntax for it on 2.6 kernels is
Here, VENDOR and MODEL are strings as reported by the SCSI hardware (typically they can be found in the system's boot messages) and the FLAGS are the same as described above; they need to be prefixed with scsi_mod. when passed on the kernel command line.

For the SLES8 kernel, the syntax is

It sets BLIST_LARGELUN | BLIST_SPARSELUN for the devices on controller number C, bus number B (normally 0) and for target ID T. Up to 8 devices can be modified this way.

Other scsi_mod parameters

scsi_mod has some other parameters that are useful when troubleshooting or configuring special setups :
  • scsi_mod.scsi_logging: a bitmask that can be used to get verbose output during SCSI scanning. Recommended values for troubleshooting are 448 (very verbose) or 128 (slightly less verbose). For definitions of the bits, refer to /usr/src/linux/drivers/scsi/scsi_scanning.h
  • scsi_mod.max_luns: the highest LUN number to scan for.
  • scsi_mod.inq_timeout: the SCSI timeout, in seconds. Some broken hardware needs larger values than the default of 6. There's one SCSI to IDE converter known to need 25. The default on the ppc64 architecture is 25.

scsi_allow_ghost_devices (SLES8 specific)

On SLES8, there is an additional parameter:


This allows to access LUNs with a unit number smaller than N to be accessed despite it reporting as offline. This is needed for some EMC storage devices.

TID history

Formerly known as TID# 10098290. Based primarily on Daniel Rahn's SDB article Options for SCSI device scanning and Kurt Garloff's page on Linux SCSI scanning troubleshooting.


This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:3955167
  • Creation Date: 19-Sep-2007
  • Modified Date:04-Mar-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.