Bug 122956

Summary: software raid partitions do not boot properly
Product: [Fedora] Fedora Reporter: Thomas Antony <thomas>
Component: kernelAssignee: Doug Ledford <dledford>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: davej, spam
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-09 17:54:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Some output from /var/log/messages
none
the requested linuxrc none

Description Thomas Antony 2004-05-10 17:57:37 UTC
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

Comment 1 Thomas Antony 2004-05-10 18:02:03 UTC
Created attachment 100138 [details]
Some output  from /var/log/messages

Comment 2 Doug Ledford 2004-05-12 17:31:38 UTC
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.

Comment 3 Jeremy Katz 2004-05-12 20:38:56 UTC
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?

Comment 4 Thomas Antony 2004-05-17 09:23:18 UTC
Created attachment 100260 [details]
the requested linuxrc

Comment 5 Thomas Antony 2004-05-28 11:55:35 UTC
I installed FC2 i386 with LVM on a other machine. The same problems
appears there.

Comment 6 Jeremy Katz 2004-06-08 18:37:49 UTC
RAID1 is loaded (see the linuxrc) -- throwing back at Doug

Comment 7 TGS 2004-09-09 01:19:31 UTC
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.



Comment 8 Dave Jones 2004-12-07 05:56:18 UTC
ok to close this ?  things still ok with the 2.6.9 kernel ?


Comment 9 Thomas Antony 2004-12-09 15:35:38 UTC
kernel 2.6.9 solved it for me.