[KLUG Members] Re: Setuing up an ADAPTEC RAID ATA 2400A card under linux

[Bryan J. Smith]

Alain DESEINE wrote:
> Sorry for the intrusion,
> but i've read a thread on the net where you wrote this :
> I currently need to install in an existing linux server (kernel 2.4.0) an
> ADPATEC 2400A RAID card, without reinstalling the whole system from
> scratch. As i was reading your contribution, i realize that it's what i
> need to do. The server is a production email server, and i need to have a
> very litle offline delay !!!!
> So if you can give me some tricks or some informations about these
> manipulation it will be very valuable for me ...
> Sorry again for this intrusion, and many thanks for your response.
> Best regards,

- Step 1:  Integration/test of controller/drive

Put the new controller and disks in the working system _alongside_ the
old.  Make sure it doesn't boot first, so you don't mess up your BIOS
disk IDs (and keep LILO from booting correctly, thinking BIOS disk 0x80
-- i.e. first fixed disk -- is /dev/hda when the BIOS is setting 0x80 as
/dev/sda ;-).  Your BIOS should allow you to choose what disk to use
first (SCSI/off-board/blah v. ATA/IDE/HDD-0/blah v. etc...).  Stick with
the latter-type (we want 0x80 = /dev/hda).

Now download and configure the driver for your Linux kernel.  Load the
driver module and make sure you can access your controller/disks (should
be /dev/sda).

- Step 2:  Partition/format/mount

Partition and format the new drives on the new controller.  Ideally (for
the copy step below), you should be making _at_least_ 1-to-1 partitions
(although it's not necessary).  If you want to add more (e.g., split of
/var/spool or /var/spool/mail), go ahead and do so (split off /tmp and
/var if you already haven't -- I always do /usr, /home and /var/spool on
a server too -- sometimes multiple /var/spool/BLAH based on the spoolers
used, /var/www for web, etc... ;-).  Now mount the new / (root) under
/newdrive.  Make the other mount points, and mount them under /newdrive
as well (i.e. new /usr goes under /newdrive/usr, etc...).

- Step 3:  Copying

This is actually not too difficult.  Assuming your new drive is
/newdrive, here is the "basic" command (BASH shell) example:

  # for _origpart in / /tmp /var /usr /home; do
  > cd $_mypart;
  > find . -mount -print | cpio -pmdv /newdrive${_origpart};
  > done

[ NOTE:  The "#" and ">" are prompts from the BASH shell ]

This assumes you have original filesystem partitions of /, /tmp, /var,
/usr and /home.  The "-mount" option (sometimes "-xdev" on older UNIX
systems) to find tells it *NOT* to cross filesystem boundaries (which
includes *NOT* going into /proc, or /dev if you use devfs -- but it
*DOES* copy /dev if you are *NOT* using devfs, which is necessary, *see
below* -- as well as not to grab /tmp when doing /, hence why we call
/tmp, then /var, etc... ;-) when printing pathnames.

We "pipe" the list of pathnames from "find" to the "cpio -p" (copy I/O
"passthru" mode), which takes the pathname, and copies it verbatim. 
This means symlinks _are_ preserved, special nodes (block/char devices,
etc...) are copied as "nodes" and do *NOT* access the devices (quite
_unlike_ "cp -dpR"!).  You can use the "-u" option ("cpio -pmdvu") to
unconditionally overwrite files that may already exist in the
destination directory -- if you need to "retry it" -- although I never
have had to -- e.g., if you "cancel" admist stream, not using "u" means
files that are already _completely_copied_ are just not copied again
(again, _rarely_ does "u" become necessary).

Assuming you mounted all your new partitions in /newdrive correctly,
everything is "expanded" there into the correct directories.  _Usually_
attributes on the filesystems themselves _are_ copied over (but its good
to check to make sure).  E.g., if /tmp is its own filesystem, usually
the attributes are set on /newdrive/tmp just like /tmp -- because /tmp
is usually 1777 permissions, and when you make the "dummy mount
directory" under /newdrive/tmp the first time, it usually makes it with
the default 0755 permissions.  The find|cpio operation _should_ copy
over even the root of a filesystem's correct permissions.

- Step 4:  Edit /newdrive/etc/fstab, /newdrive/etc/lilo.conf

Edit the /newdrive/etc/fstab.  You should know what your partitions will
be.  Remember, the Adaptec card is /dev/*s*da (not /dev/*h*da).  And
make sure you're editing /newdrive/etc/* and *NOT* the "current" /etc/*
files!  ;-P

Editing /newdrive/etc/lilo.conf is a bit tricker.  Now /dev/hda ->
/dev/sda should be easy or the most part.  *BUT* some BIOS-LILO
combinations take "issue" with BIOS being disk 0x80.  So we're going to
tell LILO to see it that way.  Put at the _very_top_ of the
/newdrive/etc/lilo.conf file:
   disk=/dev/sda
      bios=0x80

Okay, those are now configured, but don't install LILO just yet.

- Step 5:  Boot floppy/CD.

This is the "tricky part."  Usually, I make a boot floppy/CD (especially
for new Adaptec/3Ware ATA RAID cards).  If you don't have one, check out
"Mindi Boot [disk creator]" which is part of the "Mondo Rescue" package
(a full CD/tape backup/disaster recovery solution recently featured in
Linux Journal, December 2001 I believe?).  Just use "Mindi" *NOT*
"Mondo".  I toasted my partition table "testing" Mondo (because it's
designed to "backup and restore w/wipe" ;-).

Verify your Mindi boot floppy/CD boots and "sees" the new controller
when booted on its own.

Step 6:  Update LILO on new controller/drives

Okay, rip out the old drives.  Setup your BIOS to boot SCSI/off-board. 
BIOS disk 0x80 (first fixed disk) should be the Adaptec drive (/dev/sda)
in Linux.  Boot the floppy/CD.  Get to a prompt.  Make a /newdrive
directory (the current / should be a ramdisk right now, so you can write
to it) and mount the new root filesystem in it.  E.g.,:
   mkdir /newdrive
   mount /dev/sda1 /newdrive

Now chroot to /newdrive and run lilo:
   chroot /newdrive
   /sbin/lilo

And last but not least, exit chroot _umount_ /newdrive
(_very_important_):
   exit
   umount /newdrive

[ Otherwise, you might not write your LILO changes, plus your new /
(root) will be "unclean" if you do not _manually_umount_. ]

You should now be able to boot.

-- Bryan

-- 
Bryan J. Smith, Engineer          mailto:b.j.smith@ieee.org
AbsoluteValue Systems, Inc.       http://www.linux-wlan.org
SmithConcepts, Inc.            http://www.SmithConcepts.com