From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6)
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC2 test 3 on software raid 1 partitions
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
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
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.