Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 236666 - RFE: Need to update mkinitrd to use mdadm instead of raidautorun to assemble arrays
RFE: Need to update mkinitrd to use mdadm instead of raidautorun to assemble ...
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
Depends On: 213586
Blocks: 230860
  Show dependency treegraph
Reported: 2007-04-16 21:54 EDT by Doug Ledford
Modified: 2008-04-04 12:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 12:31:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix to previous attachment (794 bytes, patch)
2007-05-30 04:43 EDT, Jan Engelhardt
no flags Details | Diff

  None (edit)
Description Doug Ledford 2007-04-16 21:54:11 EDT
+++ This bug was initially created as a clone of Bug #213586 +++

In order to support updating anaconda to create mdadm raid arrays that use
version 1.0 or later superblocks, we have to quit use raid autorun from the
kernel.  The kernel does not support autorun on raid arrays with a superblock
version of 1 or higher.  Anaconda already writes out the information needed to
uniquely identify each array by UUID to /etc/mdadm.conf at startup, so the
following changes should be sufficient: any time we have $raiddevices to start,
install mdadm.static as mdadm and /etc/mdadm.conf as itself on the initrd image,
then when we loop through the $raiddevices list, instead of creating nodes and
calling raid autorun, create the node then call mdadm -A --scan /dev/$dev in the
rc.linux script.  The attached patch implements this behavior.

-- Additional comment from dledford@redhat.com on 2006-11-01 22:27 EST --
Created an attachment (id=140076)
mkinitrd patch to fix issue - tested and working

-- Additional comment from oliva@lsd.ic.unicamp.br on 2007-01-22 12:34 EST --
I'd suggest adding --run and --auto-update-homehost to the mdadm command line,
such that it will start degraded arrays (wouldn't it suck to be completely
unable to boot because your / went degraded?) and to enable other
failure-recovery scenarios after bringing disks from other machines.

-- Additional comment from dledford@redhat.com on 2007-04-16 21:52 EST --
--auto-update-homehost defeats the purpose of having a homehost in the first
place when on  a NAS/SAN.  You need to be required to do that manually,
especially since you should never be changing the home host of your boot or /
partitions unless you change them together.  If you do want to change them
separately, then rescue mode on the CD is fine.  However, the --run parameter is
perfectly fine. 

I will note that this bug has been languishing, and I'm pretty sure that the
combination of this and the total lack of a few sanity rules in the anaconda
installer has resulted in bug 230860.  If at all possible, this needs fixed
prior to F7 going gold.  I'll open a separate bug (or two) against anaconda.

Note: without fixing this, it's possible for users to create an installation
that is guaranteed to never run their raid arrays properly at bootup.  Raid
autorun is dying, and will be totally dead in the future.  This is needed to
start raid arrays without raid autorun.
Comment 1 Jan Engelhardt 2007-05-30 03:39:23 EDT
Indeed. ( http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html )
IMO, FC should just switch away from nash entirely. Perhaps have a look at suse,
which uses a regular sh+tools only.
Comment 2 Jan Engelhardt 2007-05-30 04:43:29 EDT
Created attachment 155663 [details]
Fix to previous attachment

Previous patch did not work for me (it created <initrd>/bin/mdadm/sbin/mdadm
instead of <initrd>/bin/mdadm), so here's an updated one.
Comment 3 Bug Zapper 2008-04-04 02:52:34 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 4 Alexandre Oliva 2008-04-04 12:31:47 EDT
mkinitrd has used mdadm for at least a couple of Fedora releases already.

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