Your message dated Wed, 25 May 2005 16:38:37 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Acknowledging NMUs
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 21 May 2005 20:32:05 +0000
>From [EMAIL PROTECTED] Sat May 21 13:32:05 2005
Return-path: <[EMAIL PROTECTED]>
Received: from smtp-vbr9.xs4all.nl [194.109.24.29]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DZadh-0003sz-00; Sat, 21 May 2005 13:32:05 -0700
Received: from banaan.xs4all.nl (banaan.xs4all.nl [80.126.2.237])
by smtp-vbr9.xs4all.nl (8.12.11/8.12.11) with ESMTP id j4LKW3HD083693
for <[EMAIL PROTECTED]>; Sat, 21 May 2005 22:32:04 +0200 (CEST)
(envelope-from [EMAIL PROTECTED])
Received: (from [EMAIL PROTECTED])
by banaan.xs4all.nl (8.11.6/8.11.6) id j4LKW3r30330
for [EMAIL PROTECTED]; Sat, 21 May 2005 22:32:03 +0200
Date: Sat, 21 May 2005 22:32:03 +0200
From: Erik van Konijnenburg <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: mdadm auto processing with patch
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Virus-Scanned: by XS4ALL Virus Scanner
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: mdadm
Version: 1.9.0-2.1
Severity: wishlist
The mdadm package can automatically create device files when
assembling drives, provided the auto=md or auto=part7 option
is added to the relevant drives in the configuration file.
It turns out these configuration options are often forgotten
by users, with the result that the mdadm init.d script will
not create these devices, causing bug reports such as #273182.
Thus, there is a need to automatically create these devices
even if that's not specified in the config file.
There is a command line option to do this (mdadm -A -a /dev/md0),
but in combination with the --scan option this does not work.
The reason is that the absence of auto= in config file overrules
the presence on the commandline. The attached patch changes this
by making the command line --auto option a default for the
configuration file option.
The interaction with auto=md vs auto=part is worth noting.
In the config file, auto values "yes" and "md" mean that
a non-partitionable device must be created; this is represented
in core with '-1'. "No" and absense of the option mean not to
generate a file; represented by '0'. "part", "mdp", or "part7"
mean that a partitionable device must be created, represented
by a a positive number that indicates how many partitions are needed.
On the command line, "yes" and "md" are not the same. "yes" means
that the type must be derived from the filename, (represented by -2),
"md" (is -1) asks explicitly for non-partitionable device. Like the
config file, auto=part3 is represented by a positive number. On the
command line, --auto without '=' is interpreted as --auto=yes.
The patch uses the config file value if it differs from no/absent (0),
the command line value otherwise:
(array_ident->autof ? array_ident->autof : autof));
This means auto=part7 in the config file will overrule a --auto=yes
on the command line.
It also means auto=no in config file is now overridden by --auto=yes.
This differs from previous behaviour, and can't be changed without
changing the representation of auto in RAM. Let's call this an improvement
rather than a bug.
For devices such as /dev/md-root, the auto=md option in the config file
remains mandatory, since mdadm cannot determine whether partitioning
is necessary based on the file name. If the option is absent, a suitable
error message is produced.
As an aside, if this patch works OK, it may make sense to have udev
ignore md devices. That would help in moving from kernel names
(/dev/md0) which are determines by probing order toward symbolic names,
(/dev/md-root) which can be specified based on UUID, and are independent
of the orde in which hardware is detected.
Note that this is lightly tested: interactive use only, test in combination
with a revised init.d script.
Regards,
Erik
--- mdadm-1.9.0/mdadm.c 2005-05-21 18:48:49.000000000 +0200
+++ mdadm-1.9.0-hack/mdadm.c 2005-05-21 20:57:12.000000000 +0200
@@ -732,7 +732,8 @@
devlist->devname);
rv |= 1;
} else {
- mdfd = open_mddev(devlist->devname,
array_ident->autof);
+ mdfd = open_mddev(devlist->devname,
+ (array_ident->autof ?
array_ident->autof : autof));
if (mdfd < 0)
rv |= 1;
else {
@@ -759,7 +760,8 @@
rv |= 1;
continue;
}
- mdfd = open_mddev(dv->devname,
array_ident->autof);
+ mdfd = open_mddev(dv->devname,
+ (array_ident->autof ?
array_ident->autof : autof));
if (mdfd < 0) {
rv |= 1;
continue;
@@ -777,7 +779,8 @@
} else
for (; array_list; array_list =
array_list->next) {
mdu_array_info_t array;
- mdfd = open_mddev(array_list->devname,
array_list->autof);
+ mdfd = open_mddev(array_list->devname,
+ (array_list->autof ?
array_list->autof : autof));
if (mdfd < 0) {
rv |= 1;
continue;
---------------------------------------
Received: (at 273182-done) by bugs.debian.org; 25 May 2005 14:38:42 +0000
>From [EMAIL PROTECTED] Wed May 25 07:38:42 2005
Return-path: <[EMAIL PROTECTED]>
Received: from armagnac.ifi.unizh.ch (albatross.madduck.net) [130.60.75.72]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Dax1u-0002GY-00; Wed, 25 May 2005 07:38:42 -0700
Received: from localhost (albatross.madduck.net [127.0.0.1])
by albatross.madduck.net (postfix) with ESMTP id 91D608D4319;
Wed, 25 May 2005 16:38:41 +0200 (CEST)
Received: from piper.madduck.net (piper.madduck.net [130.60.75.69])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "piper.madduck.net", Issuer "madduck.net CA" (verified OK))
by albatross.madduck.net (postfix) with ESMTP id 476EB8D2431;
Wed, 25 May 2005 16:38:41 +0200 (CEST)
Received: by piper.madduck.net (Postfix, from userid 1000)
id C886A1010A28; Wed, 25 May 2005 16:38:37 +0200 (CEST)
Date: Wed, 25 May 2005 16:38:37 +0200
From: martin f krafft <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Acknowledging NMUs
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g"
Content-Disposition: inline
Organization: Debian GNU/Linux
X-OS: Debian GNU/Linux 3.1 kernel 2.6.11-9-amd64-k8 x86_64
X-Motto: Keep the good times rollin'
X-Subliminal-Message: debian/rules!
X-Debbugs-No-Ack: please spare me
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by albatross.madduck.net
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,X_DEBBUGS_NO_ACK
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
As new co-maintainer of mdadm, I herewith acknowledge my previous
NMUs, which have all persisted through the latest release, 1.9.0-4.
These bugs are therefore ready to be archived.
--=20
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
=20
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
=20
"the problem with america is stupidity. i'm not saying there should
be a capital punishment for stupidity, but why don't we just take
the safety labels off of everything and let the problem solve
itself?"
-- seen on irc
--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFClI3tIgvIgzMMSnURApCZAKDoNdD6JZNJpr52Zb5WZIl38+G8pACcD3PU
PwhpRYyuY1mIEOqFTaUwTxs=
=hG72
-----END PGP SIGNATURE-----
--2fHTh5uZTiUOsy+g--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
