The ramdisk kernels as found on the cd have limited space on their
filesystems and therefore do not have /dev entries for all the disks
that may be on a system.
On Nov 25, 2009, at 9:43 PM, "Theodore Wynnychenko"
<ted....@comcast.net> wrote:
On Sat, 21 Nov 2009 21:43:30, Marco Peereboom wrote:
When possible use hardware RAID.
...
ami is ok but has some issues.
-----
So, since I have hardware RAID, let's stick with it. Now, what if
it fails.
-----
On Sat, 21 Nov 2009 22:54:58, Nick Holland wrote:
There is more to RAID1 than duping the data to two drives and
keeping them
the same. All HW RAID systems that I have seen use some kind of
signature
to mark the drives as part of a RAID set
...
The signature that helps resolve the above has to be somewhere on the
disk. Some systems try to hide it some place the OS would never
notice
(I believe I read some tech notes on one system that stuck it on the
very last sector of the disk, with the assumption that very few OSs
ever
put anything there, I've seen one other RAID system that seemed to do
that, as the drives COULD be removed from the RAID system and used
directly on a standard controller), but others just plop it at the
front of the physical disk, and create the array in the remaining
space.
-----
Thanks for the insight. So, I decided I would look more closely at
this
situation, and see if there was a way to recover one of the RAID
disks when
it was attached to a regular SATA controller. In my particular
case, this
turned out to be easier than I expected, for reasons that I really
don't
understand, mostly because my last email was inaccurate.
Anyway, in short. I again disconnected one of the drives from the
RAID
array, and connected it directly to one of the motherboard's SATA
controllers. As before, when I tried to boot the system, I would
get a "No
O/S" message from the BIOS when it would try to boot from the hard
disk. It
appears, on this machine, that when the SATA controller is on with a
disk
connected, that's the drive it tries to boot, and does not try the
IDE drive
that is connected with the O/S on it.
So, I booted up with the 4.6 Install CD, and used the shell
provided. As I
said before, fsck did not work. Also fdisk and disklabel returned
"device
not configured." I had assumed that this was because the RAID disk
attached
to the SATA controller was not readable. But then I noticed that
fdisk and
disklabel were able to read both the main openbsd system disk (wd0),
and the
degraded raid array (sd0), but not the SATA attached RAID disk (wd2)
OR the
secondary IDE disk present (wd1). This was odd, since both wd0 and
wd1 are
fine when the system boots from the installed IDE hard disk. (BTW,
I could
find no indication in the man pages or elsewhere to suggest that
disklabel
or fdisk work differently in the shell provide by the install CD -
this is
the part I don't understand.)
Therefore, I rebooted, this time using the CD to start the boot
process, but
then pointed it at the installed system on wd0. When it came up, I
was able
to log in, and the SATA connected RAID disk was there. I could see
the
disklabel; the filesystem was clean; and all the files were there
when I
mounted it. (It appears the signature is somewhere where it does not
interfere with the OS for the MegaRaid controller.)
As I said, I don't know why the install CD did not work. But, I
really want
to say thanks for all the insight that I got from everyone. I had
not even
thought about the controller failing, and, if it had, I would have
probably
been mighty annoyed, and may have decided my data was gone for good
(this
would have probably also annoyed my user base -> wife).
But now, I know that in this situation (with this controller and a
RAID1
array), if the controller ever dies, I can recover the data by
connecting
the disk to a regular SATA controller; and I know the steps I would
need to
take. I still don't understand why it does not work directly from
the 4.6
Install CD, however.
Thanks again
Bye - ted
PS: And I still have the off-site backup in case the house burns down.
