4

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).

3
  • Paste the error messages.
    – ewwhite
    Apr 6, 2013 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, 2013 at 19:15
  • @ACKumen you should edit the question to omit mention of the error
    – Sparr
    Apr 24, 2013 at 0:54

1 Answer 1

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .