From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040506 Description of problem: There are 2 120GB SATA harddisks connected to a ASUS K8V SE Deluxe. I installed FC 2 test 3 from scratch with 3 raid 1 partitions. md0 is the boot partition with 100mb, md1 is the swap partition with 2048mb and on md2 i created 1 LVM partition with 1 VG and 6 LV's (/, /usr, /var,....). The installation went fine, but i think there is an error initializing the software raid partitions. When the raid 1 partitions are created and hit the running state, they immediately will hit the stop state again and will be successfully activated again after the device mapper is loaded. I will add a attachment with detailed output from /var/log/messages. Version-Release number of selected component (if applicable): mdadm-1.5.0-3 How reproducible: Always Steps to Reproduce: 1. Install FC2 test 3 on software raid 1 partitions Additional info: kernel-2.6.5-1.358
Created attachment 100138 [details] Some output from /var/log/messages
This is more appropriately a bug in mkinitrd. In the initrd image, we aren't loading the raid1 module before initiating the raid start sequence. Since we are on the initrd, modprobe doesn't work, the raid1 personality is not yet registered, and therefore the raid arrays don't actually get started. Afterwards, we load the raid1 module, it tries again, this time it works. Reassigning to the person in charge of mkinitrd.
I don't see anything obvious in mkinitrd that would be causing this to happen. Can you do `zcat /boot/initrd-$(uname -r).img > /tmp/initrd.nogz ; mount /tmp/initrd.nogz /mnt/floppy` and then attach the linuxrc from there?
Created attachment 100260 [details] the requested linuxrc
I installed FC2 i386 with LVM on a other machine. The same problems appears there.
RAID1 is loaded (see the linuxrc) -- throwing back at Doug
I have a two disk SW RAID1, with the following: /dev/md0 : /boot : 1 GB /dev/md1 : swap : 2GB /dev/md2 : / : 68GB After (or during) an update to a development snapshot, containing the 2.6.8-1.533smp kernel, the drives became out of sync. the "/boot" and "/" partitions on the /dev/sda device, all became out of sync with the partitions on the /dev/sdb device. The update resulted in the /dev/sda drive partitions not being updated, and the /dev/sdb drive partitons were updated. This was discovered on the reboot just after Yum updated the packages. This resulted in a situation where, when booting into grub, the system would attempt to start with an old, non-updated version of the "/boot" partition located on the /dev/sda device. Selecting the pre-updated kernel, since the new updated kernel was not an option, resulted in the machine attempting to boot. At that point, the /dev/sdb drive "/" partition of the RAID1, being /dev/md3, would start to boot. At which time the system would report that the /dev/md1, /dev/md2, and /dev/md3 RAID1 partitions were out of sync, and only the /dev/sdb drive partations would be used. Upon completion of the boot process, the "/boot" and "/" partitions were from the /dev/sdb drive, and were updated. Using mdadm to add the /dev/sda drives back into the system resulting in a succesful additions after re-sync. Problem was, now the MBR for grub was blown away on the /dev/sda drive, after the re-sync to the /dev/sdb drives. Resulting in a machine that was not bootable. Usage of a live Linux CD, and a reinstall of grub has allowed the machine to be rebootable, and the drive seems to be in sync once again.
ok to close this ? things still ok with the 2.6.9 kernel ?
kernel 2.6.9 solved it for me.