Bug 122956 - software raid partitions do not boot properly
Summary: software raid partitions do not boot properly
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-10 17:57 UTC by Thomas Antony
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-09 17:54:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Some output from /var/log/messages (7.32 KB, text/plain)
2004-05-10 18:02 UTC, Thomas Antony
no flags Details
the requested linuxrc (1.02 KB, text/plain)
2004-05-17 09:23 UTC, Thomas Antony
no flags Details

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)

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):

How reproducible:

Steps to Reproduce:
1. Install FC2 test 3 on software raid 1 partitions

Additional info:

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.

Note You need to log in before you can comment on or make changes to this bug.