Bug 494821 - dmraid sets should be activated before mdraid
dmraid sets should be activated before mdraid
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
: 494254 (view as bug list)
Depends On:
Blocks: 516998
  Show dependency treegraph
 
Reported: 2009-04-08 05:26 EDT by Hans de Goede
Modified: 2014-03-16 23:18 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 554423 (view as bug list)
Environment:
Last Closed: 2010-01-11 12:31:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2009-04-08 05:26:02 EDT
Description of problem:
initscripts currently activates mdraid sets before dmraid, but if
we have mdraid on top of dmraid (yes people do that), then the mdraid
autorun will find mdraid partitions on the native disks, if we
run dmraid first (which will remove the /dev/sdx# nodes from the
dmraid set members), then mdraid will only see the devicemapper
partitions of the dmraid set, and it should do the right thing.

This will also fix issues like those seen in bug 494254
Comment 1 Hans de Goede 2009-04-08 05:26:42 EDT
*** Bug 494254 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2009-04-08 12:25:22 EDT
Move dmraid to run as events, please. We can't prevent mdadm from being assembled incrementally.
Comment 3 Hans de Goede 2009-04-08 19:32:37 EDT
(In reply to comment #2)
> Move dmraid to run as events, please. We can't prevent mdadm from being
> assembled incrementally.  

Erm, can you be a bit more verbose on what you mean exactly? And why not just move the dmraid activation up a couple of lines, that seems like a much
easier solution to me.
Comment 4 Bill Nottingham 2009-04-09 11:25:44 EDT
mdadm has moved to event-based setup using udev rules. It's going to occur before dmraid even if you shuffle around the calls to mdadm and dmraid.

To work correctly, dmraid need to  run off the same sort of events.
Comment 5 iarly selbir 2009-05-08 19:38:03 EDT
Assigning it.

Thanks for report.
Comment 6 Bug Zapper 2009-06-09 09:28:47 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Hans de Goede 2010-01-11 10:17:48 EST
(In reply to comment #7)
> (based on comment #4 I change the component to dmraid)
> 

Yes, unfortunately that comment is no longer true, so first let me respond to
that:

(In reply to comment #4)
> mdadm has moved to event-based setup using udev rules. It's going to occur
> before dmraid even if you shuffle around the calls to mdadm and dmraid.
> 

I'm afraid that currently that is no longer true. rc.sysinit contains:

touch /dev/.in_sysinit >/dev/null 2>&1
<snip>
/sbin/start_udev

And the presence of /dev/.in_sysinit disabled the incremental mdadm
assembly from udev, so all assembly at rc.sysinit time happens through
this command (somewhat later in rc.sysinit):

# Start any MD RAID arrays that haven't been started yet
[ -f /etc/mdadm.conf -a -x /sbin/mdadm ] && /sbin/mdadm -As --auto=yes --run

Changing the component back to initscripts.

> Hans, please, could you confirm the problem is present also in F12, and update
> the version?
> 

I can confirm it is still valid, version changed.

> also, is that possible to reproduce the problem without the hardware from the
> original bug #494254? - would you add reproducer steps then, please?    

It will reproduce on any dmraid system:
1) create a BIOS RAID set in the BIOS (on intel systems add
   "noiswmd to the cmdline when installing to make them use dmraid),
   but leave atleast one normal disk
2) install with / on the normal disk, and with say /home on an mdraid set
   using the BIOS RAID set as RAID set members
3) Add rd_NO_DM to the kernel cmdline when booting the installed system, so
   that dracut will not already start the dmraid set (note F-13 anaconda will do
   this automatically).

What then happens really is quite simple, rc.sysinit says:

# Start any MD RAID arrays that haven't been started yet
[ -f /etc/mdadm.conf -a -x /sbin/mdadm ] && /sbin/mdadm -As --auto=yes --run

<snip>

        if ! strstr "$cmdline" nodmraid && [ -x /sbin/dmraid ]; then
                modprobe dm-mirror >/dev/null 2>&1
                dmraidsets=$(LC_ALL=C /sbin/dmraid -s -c -i)
                if [ "$dmraidsets" != "no raid disks" -a "$dmraidsets" != "no b
                        for dmname in $dmraidsets; do
                                if [[ "$dmname" =~ '^isw_.*' ]] && \
                                   ! strstr "$cmdline" noiswmd; then
                                        continue
                                fi
                                /sbin/dmraid -ay -i --rm_partitions -p "$dmname
                                /sbin/kpartx -a -p p "/dev/mapper/$dmname"
                        done
                fi
        fi


IOW it tries to starts the mdraid set before the dmraid set -> trouble.

This is not as an obscure setup as it first looks. some people have promise add on IDE / SATA controllers which will not allow usage of connected disks, unless
they are made part of a RAID set, but they don't want to use dmraid / BIOS RAID.

So they mark each disk as part of a single disk JBOD, and then put mdraid on top.

The solution here is to simply move the activation of mdraid, to below the
activation of dmraid (and devicemapper multipath), but leave it before
lvm / dmcrypt setup.

Regards,

Hans

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