I think your confusion is caused by two general points: (a) you are mistaken
about some of the details of how RAID now works (e.g. auto-recognition), and
(b) more importantly, you are concentrating on where you are coming from,
rather than where you are trying to get to.
Let's think about how this system will end up. Once you have retired your
IBM disk, your 3 Seagate disks will be sda, sdb and sdc. You want to have
your kernel in an unRAIDed partition on /dev/sda1. You might want to be a
little more generous than 1 Mb for this partition, in case you ever want to
test alternative kernel images. A couple more Mb won't hurt your available
space much. You have gone for matching unRAIDed partitions on sdb1 and sdc1.
This may be worth it for sdb1, in case sda fails and crashes the kernel -
you will then have to reboot from sdb. But I can't see any use for a boot
partition on sdc1. And you have forgotten about swap. Why don't you try:
sda1 boot partition
sda2 swap
sda3 RAID partition
sdb1 rescue boot partition
sdb2 swap
sdb3 RAID partition
sdc1 swap
sdc2 RAID partition
If you make boot + swap on sda and sdb equal in size to swap on sdc, then
you will have equal-sized RAID partitions.
So how are we going to get to this point? You started well, using fdisk to
mark the RAID partitions as type 0xfd, running mke2fs on the boot
partitions, and copying the RAID-enabled kernel image to them. Your raidtab
looks fine, although you will need to make the obvious changes if you accept
the scheme above (yes, at this stage, the disks will be sdb, sdc and sdd).
mkraid followed by mke2fs is right. You can simplify the copying of your
root filesystem from sda (i.e. the IBM) to /dev/md0 by piping from one tar
to another. e.g., if /dev/md0 is mounted on /mnt/ and you are currently at
/, use:
tar cvf - / | tar xpfC - /mnt
You may get some errors because of the potential recursion around /mnt (if
your whole filesystem is on one partition, you can avoid this by using "tar
cvlf" on the left side), but this should transfer your whole filesystem
across to /dev/md0 in one go.
Your /etc/fstab for /dev/md0 wants to be a little more elaborate. Apart from
including the swap partitions, cdrom etc., you also want to mount the boot
partitions, so that it's easier to change the kernel image. If you
absolutely want to minimize the size of these partitions, you could mount
them on an unorthodox mount point - say /kernela and /kernelb - containing
the kernel and nothing else. However, it might be better, at the expense of
a few extra kb in the unRAIDed partitions (for boot.b, map etc.), to stick
with the conventional scheme of placing the kernel in /boot (or is that just
a RedHat convention?) and making that the mount point for the first boot
partition (sdc1 could go on /bootb or whatever you like). If you do this,
remember to place your kernel image on the IBM disk in /boot, and copy /boot
to sdb1 and sdc1 (as they currently are), using a similar scheme to that
used for root above. You will also have to empty /boot on /dev/md0 so that
it is a suitable mountpoint. And remember that when you use this, sda will
have gone, so that /kernela or /boot will point to sda1 and /kernelb or
/bootb will point to sdb1.
This highlights one of the main points where you are going wrong. You wanted
the kernel to be /zImage. This would mean that the kernel was on the root
partition, but root is a RAID device so you can't have the kernel there. It
is going to have to be in a subdirectory off /, so that you can mount your
unRAIDed boot partition there.
Another thing about the kernel: you should have included RAID
auto-recognition when you built it. If not, build it again including this
feature, because life will be much harder without it. This may be why you
thought you needed to do raidstart. With auto-recognition enabled, the
kernel will start (and stop) the md devices, you don't need raidstart. While
you are rebuilding the kernel, it is probably best to check that you have
built support for whichever types of RAID you want into the kernel, rather
than as modules, which would be pointless (if root is RAIDed, you're not
likely to unmount it) and more complicated.
For /etc/lilo.conf, I have no experience of using the boot sector, so I will
assume that you will install to the MBR. You will need /dev/sdb1 mounted,
say on /mnt. Let's assume that you made sdb1 the new /boot. In that case
/etc/lilo.conf would read something like:
boot=/dev/sdb
disk=/dev/sdb bios=0x80
map=/mnt/map
install=/mnt/boot.b
prompt
timeout=60
image=/mnt/zImage
label=linux
root=/dev/md0
read-only
You need that disk/bios line, because lilo assumes that disk sdb is on bios
device code 0x81. But when you actually boot from this sector, you will have
removed sda, so sdb will have slipped to sda and bios device code 0x80.
You could make this lilo.conf on /dev/md0, but then you will need to have
both /dev/md0 and /dev/sdb1 mounted when you run lilo (i.e. if /dev/md0 is
mounted on /md, run "lilo -C /md/etc/lilo.conf"). This would be fairly
pointless, because this lilo.conf will be completely wrong, once you have
/dev/md0 as root. For now, why not call it /etc/lilo.conf.md (i.e. a
temporary lilo.conf in your existing /etc on the IBM disk), and run lilo -C
/etc/lilo.conf.md.
Now you can turn off your machine, unplug the IBM disk, turn back on and see
what happens. The biggest potential problem is the device name changes. Your
Raid superblocks think that the partitions are sdb3, sdc3 and sdd2, whereas
now they are actually sda3, sdb3 and sdc2. Ingo's latest patch can cope with
device name slippage. From posting to this list:
- detection of device name changes
================================
this one was actually harder than it looks like, the RAID code now
detects device name changes and runs arrays even if an SCSI disk fails
and the system gets rebooted, and all disks shift down by one letter. It
detects backwards shifts too.
But I am not clear whether, in this circumstance, /dev/md0 would be running
in degraded mode, and, if so, whether this could be fixed with a
"mkraid --force --only-superblocks". You'll need to ask Ingo or one of the
other experts about that.
Assuming you can get this to work, you will want to make a few changes to
round off the system. /etc/lilo.conf will need adjusting to look something
like:
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt
timeout=60
image=/boot/zImage
label=linux
root=/dev/md0
read-only
You will probably also want to create an alternative lilo.conf for sdb (call
it /etc/lilo.conf.sdb), in case sda fails and crashes the machine. Assuming
you have mounted /dev/sdb1 on /bootb, this would look similar to
/etc/lilo.conf.md before:
boot=/dev/sdb
disk=/dev/sdb bios=0x80
map=/bootb/map
install=/bootb/boot.b
prompt
timeout=60
image=/bootb/zImage
label=linux
root=/dev/md0
read-only
Running "lilo -C /etc/lilo.conf.sdb" will install lilo on the MBR of sdb as
well, so that, assuming you can survive the other effects of sda crashing,
you have a chance of rebooting from sdb.
This is off the top of my head, so I hope I haven't made too many clangers.
Hopefully, this will get you up and running with root-RAID.
With regard to your questions:
> 1. If I tell AHA-2940U/WB that I want disk 1 (ie., sdb) as the boot disk,
> can it boot? Remember I have sdb1 unRAIDed and sdb2 RAIDed. Can the SCSI
> adapter know which partition to load boot codes?
LILO wants to be on sda or hda, but this will work, as I have explained
above, once sdb becomes sda.
> 2. Now that I booted from sda, can I issue command "lilo" right now?
Yes, using the -C switch if you use a file other than /etc/lilo.conf, but it
won't make any difference until sdb is sda.
> 3. I know if the system can boot somehow, it can not see the RAID before
command
>
> /sbin/raidstart -a
>
> is issued. Sure I can put this command in rc.S. But, where should I put
> etc/*? In sdb1 or md0 or nowhere?
No need for any of this with auto-recognition.
> 4. I have nothing in /mnt/dev/. How do I create /mnt/dev/md0 and the other
> devices like console, sda, sdb, hda... ? Can I run /mnt/dev/MAKEDEV ...
> right now?
That's because you didn't copy /dev across in your tar. Following my
instructions should transfer /dev as well.
I hope we're getting closer. Sorry for the confusion caused by my previous,
terse instructions. Root-RAID isn't the simplest thing in the world, but it
is getting easier.
Cheers,
Bruno Prior [EMAIL PROTECTED]
