Bug 132334 - anaconda-created mdadm.conf has (fixed) typo and forces mdadm.conf.rpmnew
Summary: anaconda-created mdadm.conf has (fixed) typo and forces mdadm.conf.rpmnew
Status: CLOSED DUPLICATE of bug 136051
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
Depends On:
Blocks: FC3BugWeekQA FC4Target
TreeView+ depends on / blocked
Reported: 2004-09-10 22:07 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2005-05-13 17:20:11 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2004-09-10 22:07:30 UTC
Description of problem:
In an everything install from scratch on a box with raid devices,
anaconda creates an mdadm.conf that contains lines such as:

ARRAY /dev/md0 superminor=0

However, mdadm expects a dash in super-minor, according to the
mdadm.conf.rpmnew file created during the install.  I've actually seen
warnings/errors from mdadm related with this unknown superminor
keyword, so I know the sample config file has correct comments, and
the anaconda-generated lines are wrong.

Personally, I'd prefer anaconda to append such lines to the
mdadm-installed conf file, instead of installing them upfront and
forcing mdadm to install its sample config file as .rpmnew.

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Jeremy Katz 2004-09-13 15:22:30 UTC
Fixed in CVS.

And I can't just append it to the mdadm.conf in the package because
the mdadm.conf needs to be there before packages get installed.

Doug -- have any thoughts about making the /etc/mdadm.conf in the
package be /etc/mdadm.conf.sample (or some such) instead?  Or even in

Comment 2 Alexandre Oliva 2004-09-13 15:49:40 UTC
Does it have to be there *while* packages are installed?

If not, you could put it in, do whatever you need to do with it, then
remove it before installing packages, and then append the data at the end.

With the current arrangement, the `MAILADDR root', that should be in
the default mdadm.conf, isn't.

Comment 3 Jeremy Katz 2004-09-13 15:56:39 UTC
Yes, it has to be there for the %post of other packages.  

Added MAILADDR to the mdadm.conf I write out.

Comment 4 Alexandre Oliva 2004-09-13 16:23:33 UTC
Hmm...  Wouldn't it be nicer to take the .rpmnew file created by the
installation of mdadm, appending an `# anaconda-generated bits follow'
header and the contents anaconda generates, and then install that as
mdadm.conf at the end?  Then, if mdadm gets different defaults, you
don't have to modify anaconda at all.

Comment 5 Alexandre Oliva 2004-09-16 03:43:22 UTC
Here's another idea: since you have mdadm (the binary) in the install
(runtime) image, I suppose it wouldn't hurt to have the corresponding
mdadm.conf in there as well, and copy it to the install tree before
appending the lines you want to add?

Comment 6 Alexandre Oliva 2004-10-02 20:14:04 UTC
The typo is fixed, but the creation of mdadm.conf.rpmnew in a fresh
install is still annoying.  Adjusting the summary.

Comment 7 Jeremy Katz 2004-10-04 21:17:20 UTC
mdadm.conf is now not included in the mdadm package (thanks Doug)

Comment 8 Alexandre Oliva 2004-10-23 16:32:05 UTC
Unfortunately the way it was taken out of the mdadm.conf package means
machines that update to the newer mdadm without anaconda (or maybe
even with an upgrade) end up without a mdadm.conf.  This doesn't seem
to be a problem for me, but I suppose if you don't get raid brought up
by initrd, you won't get it brought up later either.

Comment 9 Alexandre Oliva 2005-04-18 18:25:25 UTC
So, what is the point of having an anaconda-created mdadm.conf?  Mine looks like

# mdadm.conf written out by anaconda
DEVICE partitions
ARRAY /dev/md5 super-minor=5

and it looks like the only effect of this file is to trigger a warning from
mdadm when mdmonitor starts, like this:

mdadm: only specify super-minor once, super-minor=5 ignored.
mdadm: ARRAY line /dev/md5 has no identity information.

if I remove all ARRAY lines from /etc/mdadm.conf, I don't get this warning,
mdmonitor does monitor all arrays I have, and they're all properly brought up at
boot time.  So how about we stop anaconda from generating such a useless,
warning-generating file?

Comment 10 Doug Ledford 2005-05-13 14:27:41 UTC
In general, mdadm is designed to run without a config file fairly easily.  If
you choose to have a config file and put in array lines, then they are really
only meaningful if you are going to tie the UUID of the array to a super-minor
so that a specific array always has the same minor number.  A more appropriate
line for the generated mdadm.conf file would be something like:

ARRAY /dev/md5 UUID=34f4efec:bafe48ef:f1bb5b94:f5aace52

This will uniquely identify the array and make sure if gets the right /dev/md
number.  However, this brings up a second issue.  With the current md
implementation, it's possible to have partitionable arrays (which I would like,
that way you can do something like make multipath arrays partitionable by
default, use the whole disk device for the source devices, then put the
partition table on the md device, and as long as you don't let another OS create
partition table entries that go to the end of the drive everything will work
hunky dory, and if you want to get around that then you could make multipath md
devices all have non-persistent superblocks, we could detect the multipath
devices at initrd time, and create partitionable md devices from those devices).

Anyway, the mdadm package no longer creates an /etc/mdadm.conf file, so that's
not an issue.  I agree that the current ARRAY lines don't mean much, so unless
you are going to bother putting UUID or devices= or auto= entries on the lines,
you might as well skip them.  Bouncing to Anaconda owner since this is outside
the scope of mdadm.

Comment 11 Doug Ledford 2005-05-13 17:20:11 UTC
Since this has evolved down to not liking the anaconda generate mdadm.conf ARRAY
lines, marking as a dup of 136051.

*** This bug has been marked as a duplicate of 136051 ***

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