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):
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
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.
Yes, it has to be there for the %post of other packages.
Added MAILADDR to the mdadm.conf I write out.
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.
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?
The typo is fixed, but the creation of mdadm.conf.rpmnew in a fresh
install is still annoying. Adjusting the summary.
mdadm.conf is now not included in the mdadm package (thanks Doug)
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.
So, what is the point of having an anaconda-created mdadm.conf? Mine looks like
# mdadm.conf written out by anaconda
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,
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.
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 ***