SUMMARY: Moving disks around

From: Erik Piip <piip_at_merl.com>
Date: Fri, 07 Aug 1998 23:27:42 -0400

Hi Folks,

I asked a question a while back about moving disks around on an dunix
system. Well it is done, and yes there are a couple of traps to fall into.
I'm not sure if the way I did this is the most elegant way to do it, but
that's the way it ended up happening here. If others have improvements,
I'll be happy hear from you.

Enjoy,
        Erik


Task:
=====
Replace 4 ZKPSA's with two ITI3280UD's (Dual Ultra Scsi adapters), and add
one ITI-5232E 4 port ethernet card, to the system.

Issues:
- drives
- advfs domains
- device names.
- swap devices
- Tape names
- Changer (Tape Library) name

Firstly I installed the IntraServers drivers using their install floppy.
This is a setld package that installs the necessary images into the build
directories, and then runs a script that adds the devices to the system's
config file, sys/conf/<HOSTNAME> ...

I then rebuilt the kernel, and copied it to /, with a name like vmunix-ITI.

I shutdown, removed the 4 KZPSA's and added the two, dual scsi controllers
and the quad ethernet cards. I took care to insure that the drives and
tapes showed up as the same names on the console.
As it turned out, this was no help! :-(

Rebooted in single user mode, using the new kernel.... PROBLEMS...
The kernel ran, saw the controllers, but was not able to mount root! It
appeared that all the dunix device names had changed.!! I could not mount
anything...

I removed one of the controllers, and re-installed the kzpsa, I was able to
boot my boot disk in single user mode, and make all the new devices using
/dev/MKDEV. I then re-installed the new interfaces, and re-booted in single
user mode.

/etc/fstab was still wrong, however I was able to now manually mount / by
"mount -u /dev/new_root_dev_name /". I now had a r/w root system.

Fixing the advfs volumes.
=========================
Each Advfs file domain is identified in /etc/fsdmns. Each domain has a
directory entry that incudes a symbolic link to each of the devices that
are in the domain.

For Example:
# ls -l merl2
total 0
lrwxr-xr-x 1 root System 11 Aug 6 17:41 rzb72c -> /dev/rzb72c
#
#

Each domain had to have this symbolic link changed to reflect the new
device name.

Fixing /etc/fstab
=================
Root, swap disk/s and ufs file system entries need to be updated to reflect
new device names.

Other disk related Gotchas
==========================
/sbin/swapdefault points to your default swap device. Make sure this gets
deleted, or updated!

# ls -l /sbin/swapdefault
lrwxrwxrwx 1 root System 10 Aug 2 20:32 swapdefault ->
/dev/rz72b
#

/etc/rc.config for entries will need to be updated as well.

PAGERAW="1"
PAGEFILE="/dev/rz57b"
PARTITION="rz57b"

Yes /dev/rz72b is my new swap device.

Tapes and changers.
===================
My two tapes also changed location. I deleted all references to /dev/*mt*
and on the next re-boot these were re-built automatically at their new
locations.

The changer was a problem...
/dev/mc16 no longer existed. It had moved from scsi bus 2 to scsi bus 6.

The changers device name is /dev/mc<num> where num == ((scsibus# * 8) +
unitID).
My changer was /dev/mc16, it became /dev/mc48

/dev/MAKEDEV.MC is supposed to be able to make you a new mc device... I
could not get it to work. I eventually simply made it using mknod. The
changer is major device 52. The minor device num is calculated with
mc<num> * 16384 ... thus to make mc48:

#mknode /dev/mc48 c 52 32768
# file /dev/mc48
/dev/mc48: character special (52/98304) SCSI #6 ACL4/52
special_device #384 (SCSI ID #0) (SCSI LUN #0) errors = 0/254
# ls -l /dev/mc48
crw-r--r-- 1 root System 52,98304 Aug 3 00:53 /dev/mc48
#

If you are using NSR, you will need to update /var/nsr/res/nsrjb.res to
point to the new control port name entry:
  control port: /dev/mc48;

After you have every thing running, clean out any unused devices in /dev...
There is at least one process that seems to go out and try to pole every
disk listed in the /dev directory. When it finds something missing it
forces a scsi reset, which will cause devices on the bus to re-negotiate
their scsi bus widths and speeds. This takes time.....

When you have deleted any old devices, get the running kernel back into
sync by using scsimgr.

"scsimgr -sync" will bring the kernels in memory copy of /dev/*rz* lists
in line with what is in the directory.

Traps with the ethernet card
============================
As part of this I moved my tu1 ethernet card to another slot. The console
picked it up, but the kernel dropped it. In /sys/conf/<HOSTNAME> there are
entries for all the devices as they were discovered when the system was
initially installed. This is where there device <-> names get fixed.

Look for entries like:
controller tu1 at pci1 slot 4

I changed the PCI bus number and slot number, and it came back up.

==============================

Conclusions:
If you don't know where the devices are likely to end up, make sure you
have an alternative disk you can boot, on a bus that you know has not
changed. This way you can look around and figure out what the kernel has
done with device names.

Knowing that, you should be able configure the system to come up without
too much pain.

I think that about covers all the issues that I saw.

Enjoy.

-
==================================================================
Erik Piip ph:[1]617-621-7516 fax:[1]617-621-7550
             e-mail: piip_at_merl.com
    /\ Manager of Computer Network Services
   _\/_ Mitsubishi Electric Research Laboratories
  /_/\_\ 201 Broadway, Cambridge, MA 02139
==================================================================
Received on Sat Aug 08 1998 - 03:31:37 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT