You are not logged in.

#1 2006-10-30 12:24:40

jyrihovila
Member
Registered: 2006-10-30
Posts: 13

SCSI hard drive naming problem

Hello, world!

I'm a professional data recovery engineer. I've been using the Helix live CD for Linux recoveries, but due to multiple problems (mainly the constant filling up of RAM) I installed Arch Linux on one of my workstations.

I love Arch already, but there's one problem I haven't found a solution to:

The workstation I'm using has two S-ATA drives, seen by Arch as sda and sdb. Everything is ok as long as I'm working with IDE or S-ATA drives, as sda and sdb always have the same name. However, if I connect a SCSI drive to the workstation, HD naming scheme gets messed up: SCSI drives take precedence of the S-ATA drives, so sda and sdb become sdb and sdc, sdc and sdd etc. depending on the number of SCSI drives attached.

Is there a way to fix sda and sdb so that they wouldn't "shift" when SCSI drives are added to the workstation?

Thanks in advance!

- Jyri

Offline

#2 2006-10-30 14:04:00

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: SCSI hard drive naming problem

Offline

#3 2006-10-30 14:13:30

jyrihovila
Member
Registered: 2006-10-30
Posts: 13

Re: SCSI hard drive naming problem

Thanks! smile

- Jyri

Offline

#4 2006-10-30 21:50:38

rayjgu3
Member
From: Chicago IL usa
Registered: 2004-07-04
Posts: 695

Re: SCSI hard drive naming problem

another way to go about it , is in /etc/mkinitcpio

sample

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES=" piix sata_via jbd ext3"

# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish.  This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in anyway.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
#    FILES="/etc/modprobe.conf"
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'modload' may be used in place of 'udev', but is not recommended
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
#    This setup specifies all modules in the MODULES setting above.
#    No raid, lvm, or encrypted root is needed.
#    HOOKS="base"
#
#    This setup will autodetect all modules for your system and should
#    work as a sane default
#    HOOKS="base udev autodetect ide scsi sata filesystems"
#
#    This setup will generate a 'full' image which supports most systems.
#    No autodetection is done.
#    HOOKS="base udev ide scsi sata usb filesystems"
#
#    This setup assembles an ide raid array with an encrypted root FS.
#    Note: See 'mkinitcpio -H raid' for more information on raid devices.
#    HOOKS="base udev ide filesystems raid encrypt"
#
#    This setup loads an LVM volume group on a usb device.
#    HOOKS="base udev usb filesystems lvm"
HOOKS="base udev sata filesystems"

take notice i took scsi out of HOOKS , so when/if i do plug my scsi drives into this box or swap this drive into a box with scsi drives the sata will be recognized as sda before the scsi modules are loaded
a problem i had a while back while we still used mkinitrd . i do believe this would still be the same with mkinitcpio i cant say for sure it will work but in theory i would say what i suggest would work
it will be easier to maintain then a udev rule as the syntax sometimes needs to be changed in rules like " =  is replaced with ==" or is it the other way around
or if i recall correctly it used to be  name a rule prefixed with a number now the rules get loaded in alphitical order so your rule may get overridden by the main udev.rules  cause a number is read before a letter
if im understanding correctly ,
so the 00.udev.rules are read but if udev.rules say something else about whats connected it could very well change your sata from sda to sdb or sdc
if im misunderstanding the udev loading process please let me know

Offline

Board footer

Powered by FluxBB