Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have two tape-changer robots (Quantum Superloader 3), one with parallel SCSI connectivity, the other with SAS. They were connected to a Centos 5 server, and boot would proceed normally.

They are now connected to a new server running CentOS 6.3. When the server gets to the 'Starting udev' stage, one after the other, the changers begin going through many routines, presumably some sort of inventory. The SAS changer goes first, probably because it gets assigned a lower device number ( /dev/changer-sg4 compared to the other changer's /dev/changer-sg6). While this is happening, the boot process just stays on 'Starting udev'

The first changer churns through its inventory in about 3-4 minutes, then the second changer starts. A few minutes in, I see SCSI error messages appear on the screen (I can paste them here soon if they are needed), but the changer continues doing its inventory and boot proceeds correctly from there. The changer finishes before boot does, and when boot comes up, both tape changers seem to be fully available and working.

The upshot is, bootup completes successfully without manual intervention, but I'd like to cut out the extra time this is adding to boot, and extra wear on the tape changers (if there is any).

share|improve this question
    
Paste the error messages. –  ewwhite Apr 6 '13 at 11:34
    
I don't have error messages because the circumstances have changed. The changer giving the errors actually had a hardware component misaligned, since I had taken the tape drive out from a different device and put it in this changer, and used the wrong screws. Now the alignment is perfect. Now, upon bootup, I get the scanning of both tape changers, and after about 3 minutes this completes. From there, bootup proceeds as normal, leaving behind no error messages. What I'm trying to get to is info about the scanning of the tape changers at boot. This didn't occur in CentOS 5 –  ACKumen Apr 23 '13 at 19:15
    
@ACKumen you should edit the question to omit mention of the error –  Sparr Apr 24 '13 at 0:54

1 Answer 1

Responding to your edit.

I don't think this matters. Just because something worked a certain way in EL5 doesn't mean that it should be expected to behave similarly in EL6.

You have to consider:

  • Different kernel generations...
  • Vastly different compiled-in defaults.
  • sysctl.conf settings are different.
  • Package/application config files are different...

The SCSI subsystem initialization/module loading process is probably the cause. I don't think this will cause premature wear on your drive. I doubt that there's any way to bypass the process...

You shouldn't be loading/unloading modules or rebooting often enough for this to be an issue.

share|improve this answer

Your Answer

 
discard

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.