Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236666 - RFE: Need to update mkinitrd to use mdadm instead of raidautorun to assemble arrays
Summary: RFE: Need to update mkinitrd to use mdadm instead of raidautorun to assemble ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
URL:
Whiteboard: bzcl34nup
Depends On: 213586
Blocks: 230860
TreeView+ depends on / blocked
 
Reported: 2007-04-17 01:54 UTC by Doug Ledford
Modified: 2008-04-04 16:31 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-04 16:31:47 UTC


Attachments (Terms of Use)
Fix to previous attachment (deleted)
2007-05-30 08:43 UTC, Jan Engelhardt
no flags Details | Diff

Description Doug Ledford 2007-04-17 01:54:11 UTC
+++ 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 07:39:23 UTC
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 08:43:29 UTC
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 06:52:34 UTC
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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 16:31:47 UTC
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.