Now I've done it.

I had a perfectly working server that I cherished. I swear next time I will be satisfied with "it works perfectly."

My plan was to leave my server running FC4, but to install FC5 on my scsi disks (and have fc4 on one disk and fc5 on the scsi raid and when it was working right, drop the fc4). I was going to see if FC5 would make the software raid and do the install (to test the new feature more than anything). I chickened out ("wow, why am I doing this, something is bound to go wrong," I thought), and almost everything was fine

HERE is what was running fine before my misguided exploration.
1. A single 20G disk that was running FC4 OS pretty much flawlessly.
2. A pair of ata drives that had all my files, music, photos, everything, which was software raided (/dev/md0/) and also worked pretty much flawlessly.
3. An experimental /dev/md5 scsi array that I was going to install the fc5 on.
4. A fresh (like 30 minutes old) tape backup of, hopefully, everything on /dev/md0. This is reassuring, but I hope it doesn't come to this.

HERE is what I did.
1. edited mdadm.conf to remove the md5 array before i started with fc5. There is a possiblity that I accidently changed the /dev/md0 at the same time.
2. Proceeded to install FC5. I did not tell it to do anything on the 20g disk (where the fc4 was) or the /dev/md0 array or disks. Meaning I always unchecked any of those. I told it to install on the sda and sdb scsi disks, but I never started the install. I did go to the disk druid to see if it would make the raid 0 array and at one point, I did tell it to make the array (I wanted to see if the installer would actually do it). This may have changed something which messed up the /dev/md0 array, but I don't know what.
3. I hit control alt del to stop the installation. This is where I chickened out.

NOW here is what it does.
1. Machine will run through the boot, will load the kernel, go into fedora gui and attempt to continue booting...
2. Then it dumps out of gui mode and spits out this.....
mdadm: no devices found for /dev/md0
...
...
...
fsck.ext3: invalid argument while trying to open /dev/md0 FAILED
An error occurred during the filesystem check.... them some more stuff...
..
..
Give root password for maintence......

AFTER THIS I tried to figure out the problem with fsck and e2fsk (whatever the command is), but I didn't get anywhere.

THIS MAY BE RELEVANT: my fstab file has the following for the /dev/md0 entry:
/dev/md0 mnt/alldata ext3 defaults 1 2

ONE MORE IMPORTANT ITEM. I went back into the fc5 installer, not to install, but to look at the disks. The /dev/hdd1 and /dev/hdc1 which make up /dev/md0 seem to be present, like always, with the same partitioning info. I now have a /dev/md5 (which is what I originally called the scsi raid) in the disk druid, which seems odd b/c I never saw the /dev/md0 in the disk druid (the disk druid is the thing the fc5 installer uses to show the disk structure. It sort of reminds me of the "hardware profiler"). A little later, after a bout of panic induced insomnia, I tried to mount the individual drives hdd1 and hdc1 (while in maintence mode) and they MOUNTED (yea!) and it appears as if both drives are intact and complete. (Does the disk druid use raidtools, by any chance, to make that array? If so, is it possible that is what is messing everything up. I am using mdadm to make all arrays and I think raidtools conflicts. Just thinking out loud here. The odd thing is that /dev/md5 comes up in mdadm --detail --scan even though I "commented it out" of the mdadm.conf file before I started this mess. I may be confused here, though).

So basically fc4 is fine (it was on a seperate disk), and it gets most of the way through the boot process and runs into a problem with /dev/md0, which was never a problem before I started this. I am not savy enough to just scrap it and try to restore from the tapes. I can do it if necessary, but I would rather find some way to fix the problem before I got that route. No telling what might happen.

Let me know if this is adequate or I can confuse you more !!!! Maybe this is an easy fix....

Thanks

UPDATE: I have determined that the /dev/md0 array, and the disks that build it /hdc1/ and /hdd1 are working, in sync, and have the proper UUIDs (and most importantly, at this point have all the data on them!). I can manually build the arrays and mount them. But when I restart I don't get any change.

The odd thing is that the fc4 is somehow mounting the array that the Disk Druid assembled without reading my mdadm.conf file. I believe this becaue it is mounting /dev/md5, and it's not even specified in the mdadm.conf file. I may be off base on this, but this seems to be what is happening.

Did you read the release notes re udev? Is it possible that the FC4 stuff in /etc/udev/ (if any) was changed, or that a new /etc/udev.d/ was added?