Date: Wed, 17 Apr 1996 16:10:01 -0600 (MDT) From: Brandon Gillespie <brandon@tombstone.sunrem.com> To: questions@freebsd.org Subject: Adding a new disk, odd situation... Message-ID: <Pine.BSF.3.91.960417155224.4624A-100000@tombstone.sunrem.com>
next in thread | raw e-mail | index | archive | help
I have a server running FreeBSD 2.1-R with a kernel rebuild for the BOCA
board. When we upgraded the machine from a Linux system we swapped a few
drives around, ending up with two SCSI drives. The first was a new
Conner 1.0GB SCSI F&W drive, the second was an older conner 1.3GB SCSI-2
drive. We were having problems with our SCSI controller on handling the
first drive, so we opted to just ignore it (as we doubted the controller
could handle it--odd situation, the drive actually has a SCSI-2 adaptor
strapped on the back, and was intended for macs--which it works on just
fine). Instead we installed on the second drive, which reported itself
on scsi id #6, although we dont know why (this drive has a history of its
own, it came out of an AT&T star server). We didn't want it on SCSI id
#6, but we also could not find the appropriate jumpers to change it.
Consequently we simply installed it as it stood. We left both drives
connected, with the first 1.0GB conner on scsi id #0, and installed to
the second. There are a few problems with this. Primarily, to boot we
have to boot with 'sd(1,a)/kernel' to get the right drive.
Act 2:
I now have two quantum SCSI drives I want to drop into the place of the
first drive. One is a Quantum Lighting and the other is simply a Quantum
(I dont recall the actual model, and I can't get to it at the moment).
Replacing the conner with the quantum lighting resulted in some very
interesting behavior, from the drive controller (before we even hit the
OS); usually the controller (adaptech) reports each drive it finds upon
bootup, similar to
DRIVE-NAME DRIVE-SPECS #ID C: (etc)
With the lighting in place it came up on id 0, with drive specs, then id
1-5 were also the quantum lighting, but only in name (it didn't give the
specs (size etc)), and finally ending with the conner 1.3 on id 6. When
I reached the boot prompt I intended to boot to the conner, but I
couldn't find the filesystem device for it anymore... (it was no longer
on sd0). I could have booted from a floppy to let the OS probe the
device, but I was rather rushed at the time, so instead I simply removed
all drives other than the conner 1.3 gb and did another reboot, this time
specifying sd(0,a)/kernel. It reached the point of doing an fsck when it
came up with a device-not-configured error (for obvious reasons, as sd1
was the configured device)... At this point I simply plugged back in the
original conner to sd0 and rebooted to sd1 on the second conner without
problems, leaving it for another day..
Act 3:
This saturday I have aquired more available down-time to work on the
problem. What I would like to know is what tools are available, and what
would have to happen to get around specific possibilities, namely:
1) How would one reconfigure a different scsi device for an existing
filesystem? This is in relation to if I end up having to keep
the existing filesystem (which we need) on a device other than
sd1...
2) with the new disk, how do I make it a 'bootable' disk? I.e.
I doubt simply copying the core filesystem from the current disk
to the new disk will work (once the new disk is formatted). What
I would really like is the possibility of using dd to just copy
the entire disk across, except for the disk sizes are not the same
(the quantum is only 540 MB), even though we have only used
400MB of the 1.3 GB available. I would like to set it up to boot
to the quantum, with the core filesystem on the quantum and the
users on the conner...
-Brandon Gillespie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960417155224.4624A-100000>