Linux Boot Options.

[MSwift]

Is there an option in RHEL5 to skip the SAN disks to speed up the boot so that it would scan only the internal disks? SAN is attached but we are not using them now.

Thanks

Mike.

[Jimmy Vance]

if your talking about fsck running after "x" amount of boots, change the options in /etc/fstab

[dirk dierickx]

also not sure of which stage in the boot process you're talking about. but you could for example build an initrd without fibre card modules.

[MSwift]

Here is our problem. We currently have SAN attached (for oracle pupose) but they are not used at the moment, they are just attached. Since RHEL 5 sees them it is scanning all the disks during the boot and this takes time. we just want to make sure the system boots fast. So, is there an option in the startup scripts or any other place to disable all the SAN so that the server could boot up fast!

Thanks

Mike

[Jimmy Vance]

If you don't like any of the suggestions so far, another option is to unplug the fibre cables.

What does it matter how long it takes to boot? Once a server is up, the norm is not to reboot it often.

[Matti_Kurkela · Accepted solution]

I guess the "scan" you mention is the HBA detecting the LUNs available on the SAN, since if the disks are not used, there should be no mention of them in /etc/fstab and therefore the system should not be attempting to run a filesystem check.

Things you might want to do:

- If you have SAN switches, do you have zoning configured? If you haven't, each host might attempt to probe all the LUNs in the entire SAN... no wonder your boot is slow in that case!

- If you want to completely disable the SAN functionality, the easiest way would be to disable the HBA driver modules. Edit /etc/modprobe.conf: comment out the "alias scsi_hostadapter* " lines, and add a line like "blacklist ". Then run "depmod -a" and re-create your initrd (see "man mkinitrd" for examples).

MK

[Jayakrishnan G Naik]

Hi MS

I have used another way to tackle similar situation by disabling the fc device in bios.
This can be done only if the lun are just raw, and if any volume manager uses it/filesystem exists, the OS will throw error.

I faced similar issue when I perform automated unattended OS "re-installation" of linux when disks and luns co-exist, the automated installation given me problems when it was not able to identify which device to use (disk or lun). I disabled the PCI device in bios and gone ahead with the installation and after the installation I enabled the PCI device to make use of the luns.

Mine was an HP BL 460 G6 server with qlogic card where it can be disabled in bios.
Try if it is applicable for you too.

Thanks & Regards
Jayakrishnan G Naik

[MSwift]

Thanks MK!

The modified modprobe.conf, will it look like this?
alias eth0 bnx2
alias eth1 bnx2
alias eth2 e1000e
alias eth3 e1000e
alias scsi_hostadapter megaraid_sas
alias scsi_hostadapter1 ata_piix
#alias scsi_hostadapter2 qla2xxx
blacklist qla2xxx
alias scsi_hostadapter3 usb-storage
alias net-pf-10 off
alias ipv6 off
###BEGINPP
include /etc/modprobe.conf.pp
###ENDPP

Also after running depmod -a, what would be the exact mkinitrd command to load the new module with the edited modprobe.conf file? This would really help..

Thanks

Mike.

[Zinky]

Why don't you try to "fix" the issue with your SAN LUNs dragging your OS startup instead of completely masking them out?

My systems have over 1000 HP StorageWorks LUNs (yes EVA/XPs), ASMLib used by Oracle and they still boot in under 15 minutes.

We used to have the same issues as you likely are encountering and it was a wild journey for us finally fixing the issue. It used to take over an hour to never for our mega-SAN environments to boot.

The fixes we've employed are as follows -- (Matti I think we should have a Linux Mega-SAN HOWTO and Fixes in the Linux threads to HELP out others):

1.) LVM SCAN Filter needs to be fixed (modify your /etc/lvm/lvm.conf's filter line so LVM only scans the disks that it should scan)

2.) ASM or ASMLib disktring or scan directives. Work with your DBA and come up with standards how Oracle should use your SAN LUNs -- use friendly multipath names to make it easy for ASM/ASMLib/Oracle to have a distinct disk string. ALso decide if you would want to partition your LUNs or use them whole...

Fix the above 2 and your boot times will be acceptably "acceptable"

[MSwift]

Good suggestion Alzhy! Still needed the exact mkinitrd command that Matti recommended.

Thanks

Mike

[Zinky]

cd /boot
cp -p initrd- initrd-/BAK
mkinitrd -f -v initrd-

where kernel is : uname -r


Hope this helps.

[Zinky]

I still suggest you fix your boot dragginess issue with SAN LUNs enabled. I am seeing this issue in about 9 of 10 Colleaugues out there.

Symptoms of a misconfigured LVM.CONF that drags down boot up times of SAN connected systems are those "Duplicate PVs" detected on boot up or doing LVM gyrations.

Work also with your DBA to get your /etc/sysconfig/oracleasm config file to have ASMlib scan only what it should scan as well as "disk sting" within the Oracle ASM Instance.

I forgot to add, sometimes the issue would be with "Ghost LUNS" being seen by the Linux scsi stack. We've bee bitten by this on XP Arrays... There is a setting in the hostgroup definition to do away with Ghost or zero sized LUNs being presented,

[brian_31]

Alzhy

What is that setting?

Thanks

Brian.

[Zinky]

That setting "varies" from SAN Array to another. On the HP Storageworks XP line - it is a HostGroup property -- ask your SAN admin if your array has that peculiarity.

[MSwift]

closing now..Thanks all

Mike