Debian Bug report logs - #273182
udev doesn't create /dev/md* in time for mdadm-raid to start them. All sw-raid filesys fail to mount.

version graph

Package: mdadm; Maintainer for mdadm is Debian mdadm maintainers <pkg-mdadm-devel@lists.alioth.debian.org>; Source for mdadm is src:mdadm.

Reported by: Greg Folkert <greg@wamgr.com>

Date: Fri, 24 Sep 2004 13:03:04 UTC

Severity: critical

Tags: confirmed, fixed, patch

Merged with 284028, 294404, 310126

Found in versions 1.7.0-2, 1.9.0-1, 1.9.0-2.1

Done: martin f krafft <madduck@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#273182; Package udev. Full text and rfc822 format available.

Acknowledgement sent to Greg Folkert <greg@wamgr.com>:
New Bug report received and forwarded. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Greg Folkert <greg@wamgr.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: udev doesn't create /dev/md* in time for mdadm-raid to start them. All sw-raid filesys fail to mount.
Date: Fri, 24 Sep 2004 08:59:48 -0400
Package: udev
Version: 0.031-2
Severity: important

Filesystems shown are succesfully started when udev is not installed. They boot just fine without any failures.

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md1               1989568     62356   1927212   4% /
/dev/md0                141760      6932    134828   5% /boot
/dev/md4               9989504       292   9989212   1% /home
/dev/md3                995008       660    994348   1% /tmp
/dev/md5              15426176    273940  15152236   2% /usr
/dev/md2               9989504     80676   9908828   1% /var

As soon as udev is installed all filesystems except /dev/md1 fail, as /dev/md1 is started by linuxrc in the initrd.

I have been able to seed in a workaround in initrd-tools.sh at the end to manually create these /dev/md*.

----------begin workaround

    if [ ! -f /dev/md0 ] && [ -x /bin/mknod ] ; then 
        for i in 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ; do
            node="/dev/md$i"
            /bin/mknod $node b 9 $i || /bin/echo "error mknod \"$node\" create failed"
            /bin/chmod 0660 $node || /bin/echo "error chmod \"$node\" failed"
        done
    fi

----------end workaround

The Debconf info was just the warnings as I installed udev to make it easier to use reportbug.

I have tried a dev.d script and it still does not create the /dev/md* device nodes early enough.

The kernel modules for md and raid* are inserted as the first modules it loads. So it cannot be the modules being loaded 
soon enough for udevd to notice.

Either I am missing something obvious or it is somehow brokeon or slowed.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7 (2.6.8-3)
Locale: LANG=C, LC_CTYPE=C

Versions of packages udev depends on:
ii  debconf [debconf-2.0]    1.4.36          Debian configuration management sy
ii  hotplug                  0.0.20040329-15 Linux Hotplug Scripts
ii  initscripts              2.86-5          Standard scripts needed for bootin
ii  libc6                    2.3.2.ds1-16    GNU C Library: Shared libraries an
ii  libnewt0.51              0.51.6-16       Not Erik's Windowing Toolkit - tex
ii  makedev                  2.3.1-75        Creates device files in /dev

-- debconf information excluded



Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#273182; Package udev. Full text and rfc822 format available.

Acknowledgement sent to Marco d'Itri <md@Linux.IT>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #10 received at 273182@bugs.debian.org (full text, mbox):

From: Marco d'Itri <md@Linux.IT>
To: Greg Folkert <greg@wamgr.com>, 273182@bugs.debian.org
Cc: control@bugs.debian.org, debian-kernel@lists.debian.org
Subject: Re: Bug#273182: udev doesn't create /dev/md* in time for mdadm-raid to start them. All sw-raid filesys fail to mount.
Date: Fri, 24 Sep 2004 15:12:57 +0200
reassign 273182 kernel-source-2.6.8
thanks

On Sep 24, Greg Folkert <greg@wamgr.com> wrote:

> Either I am missing something obvious or it is somehow brokeon or slowed.
This is a kernel bug which needs to be fixed in the kernel and in the
raid userspace tools. I will reassign the bug, but the situation is
already well known upstream.
If you want to use udev and raid you need a kernel with a statically
compiled driver and RAID autostart enabled.

-- 
ciao, |
Marco | [8159 di3vIJjInwb/E]



Bug reassigned from package `udev' to `kernel-source-2.6.8'. Request was from Marco d'Itri <md@Linux.IT> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #17 received at 273182@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: Adi Kriegisch <Kriegisch@vrvis.at>
Cc: 282635@bugs.debian.org, 273182@bugs.debian.org
Subject: Re: Bug#282635: Same with Software Raid
Date: Tue, 7 Dec 2004 19:47:34 +0100
[Message part 1 (text/plain, inline)]
On Dec 07, Adi Kriegisch <Kriegisch@vrvis.at> wrote:

> I was unable to find a single reference to a kernel bug. This rather seems to 
#273182

> I would really expect either a warning message or a "silent" migration that 
> creates all necessary raid devices in /dev as it is suggested here for 
> example:
Why don't you ask the debian kernel maintainers to add that workaround
to their package instead? It's the kernel which is broken, I think that
ugly workarounds should go in the package which requires them.

> PS: what do you mean by raid autorun? IMHO /etc/init.d/raid2 start trys 
in-kernel autostart of RAID devices, i.e. the standard debian kernel
does not work because the md driver is modular.

-- 
ciao, |
Marco | [9640 merfKdlFJrg0U]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Acknowledgement sent to Donovan Baarda <abo@minkirri.apana.org.au>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #22 received at 273182@bugs.debian.org (full text, mbox):

From: Donovan Baarda <abo@minkirri.apana.org.au>
To: 273182@bugs.debian.org
Cc: Donovan Baarda <abo@minkirri.apana.org.au>
Subject: A fix, and diagnosis of some udev issues.
Date: Wed, 29 Dec 2004 23:35:21 +1100
G'day,

I hit this when migrating to udev on a system with SATA HDD's used for a
md0 RAID0 filesystem mounted as /var/local (non-root).

IMHO the udev excuse of "make the kernel mantainers compile md into the
kernel as a workaround" is a very bad idea. The problem is definitely an
interaction issue with the kernel, udev, and mdadm. They are equally to
blame, so the fix/workaround will require them to co-operate on it.

Here are the things required to make it work on my system;

1) Add the SATA module specific to my hardware (sata_sil)
to /etc/modules.

2) Add the following to /etc/udev/links.conf;

  # create md devices.
  M md0           b 9 0
  M md1           b 9 1
  M md2           b 9 2
  M md3           b 9 3

3) modify /etc/init.d/mdadm-raid as follows;

--- pirli.3/init.d/mdadm-raid Fri, 10 Dec 2004 22:41:39 +1100 
+++ pirli.5(w)/init.d/mdadm-raid Wed, 29 Dec 2004 21:13:58 +1100
@@ -19,6 +19,8 @@
 case "$1" in
     start)
        if [ "x$AUTOSTART" = "xtrue" ] ; then
+           # give udev time to create /dev/sd* devices
+           sleep 3s
             if [ ! -f /proc/mdstat ] && [ -x /sbin/modprobe ] ; then
                 /sbin/modprobe -k md > /dev/null 2>&1
             fi


And here is a diagnosis and analysis of each fix;

1) on my system, the sata_sil driver is automatically detected and
loaded by hotplug. It seems recent versions of discover also detect and
load it (older versions didn't). Unfortunately, this module needs to be
loaded before mdadm-raid's rc script runs at priority 25
(/etc/rcS.d/S25mdadm-raid). hotplug runs at priority 40, and discover
runs at 35, so they are both too late in the boot process. /etc/modules
is loaded by module-init-tools at priority 20. People using root-raid
will already have made sure the required modules are loaded in the
initrd, so they will not hit this.

Another possible solution would be to change mdadm-raid's priority so
that it runs after discover, but then checkfs.sh at priority 30 will
fail... I wonder if you should be checking filesystems before required
modules are loaded (by discover)... Note checkfs.sh only checks non-root
partitions, as root is already mounted at that point. Perhaps a policy
of "all devices should be loaded before non-root filesystems can be
checked/mounted" would be a good idea?

2) It seems that the combination of the md kernel module and mdadm do
not give udev the required notification to create the /dev/md* devices.
It is not that they are created too late for mdadm-raid... they are not
created at all. The discussion here suggests that there is a kernel bug
contributing, and various doc's suggest some modules do not or can not
give the required notification. It seems the md module is one of these.
Fortunately udev has a workaround for devices that don't have support
for correctly notifying udev, /etc/udev/links.conf.

3) It seems udev can take a disturbingly long time to create the /dev/*
device files after a module is loaded. This took me a long time to
diagnose... on bootup mdadm kept complaining that it couldn't find the
md0 devices, but when I ran it manually it worked fine. On my system,
sata_sil is loaded using /etc/modules (see fix 1), and when the
mdadm-raid rc script ran, there were no /dev/sd* devices (there
were /dev/md* devices, see fix 2). A delay of at least 3 seconds was
required before these devices appeared and mdadm-raid would work. I
suspect on systems with more partitions this could take longer.

Note that this delay could affect any rc-script that required /dev/*
devices to exist for devices loaded by /etc/modules. I added the delay
to /etc/init.d/mdadm-raid because that's where it was hurting me.
Ideally modprobe should delay until udev has finished creating the
device files. If this is not possible, probably a better alternative
would be to add the delay to the end of /etc/init.d/module-init-tools.

So who's bug is it, and who should fix/workaround it?

part 1) is probably a user problem... the user will just need to put the
required modules into /etc/modules. Arguably the rc-script priorities of
discover, hotplug, and checkfs.sh (initscripts package)  could be
tweaked to fix this.

part 2) is possibly a kernel bug, or possibly a mdadm bug, but the
cleanest workaround would be to add the required changes
to /etc/udev/links.conf, either as a default or at least a README in the
udev package.

part 3) is definitely a udev issue. Ideally it would be fixed so module
loading with modprobe would wait until the /dev/* files are created. I
find 3 seconds disturbingly long... I realise udev would have to scan
partitions, but 3 seconds! If it was made faster this problem would
probably go away. Failing a proper fix, the cleanest workaround is to
add a delay after the /etc/init.d/module-init-tools rc script runs. As
it's a udev specific problem, have the udev package add
an /etc/init.d/udev-wait rc script that runs at priority 21 that delays
to give udev time to create the devices.

Given that 2 out of 3 of the fixes/workarounds suggest udev changes, I'd
be inclined to fling this bug back at udev... perhaps also file a
wishlist bug against initscripts to make the device autodetection and
checkfs.sh rc priorities a bit better.

-- 
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Acknowledgement sent to Greg Folkert <greg@gregfolkert.net>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #27 received at 273182@bugs.debian.org (full text, mbox):

From: Greg Folkert <greg@gregfolkert.net>
To: 273182@bugs.debian.org
Subject: Certain things don't add up....
Date: Sat, 05 Feb 2005 01:09:04 -0500
[Message part 1 (text/plain, inline)]
Comments in-line.

Donovan Baarda <abo@minkirri.apana.org.au> is quoted as saying:

        So who's bug is it, and who should fix/workaround it?

        part 1) is probably a user problem... the user will just need to
        put the required modules into /etc/modules. Arguably the
        rc-script priorities of discover, hotplug, and checkfs.sh
        (initscripts package) could be tweaked to fix this.
        
This is entirely unsatisfactory, adding lines
to /etc/modules? /etc/modules is deprecated and should not be around if
you are using modprobe, hotplug, discover..et-al. This is just bad
advice or workaround.
        
        part 2) is possibly a kernel bug, or possibly a mdadm bug, but
        the cleanest workaround would be to add the required changes
        to /etc/udev/links.conf, either as a default or at least a
        README in the udev package. 
        
Wow this is great, tell us to use a file which explicitly has this as
its header:

    # This file does not exist. Please do not ask the debian maintainer about it.
    # You may use it to do strange and wonderful things, at your risk.

So you propose to have this fugly hack in a Production system? (later
when Sarge is released. I'd like to think not.
        
        part 3) is definitely a udev issue. Ideally it would be fixed so
        module loading with modprobe would wait until the /dev/* files
        are created. I find 3 seconds disturbingly long... I realise
        udev would have to scan partitions, but 3 seconds! If it was
        made faster this problem would probably go away. Failing a
        proper fix, the cleanest workaround is to add a delay after
        the /etc/init.d/module-init-tools rc script runs. As it's a udev
        specific problem, have the udev package add
        an /etc/init.d/udev-wait rc script that runs at priority 21 that
        delays to give udev time to create the devices.
        
Ouch, 3 seconds on relatively small systems might just work. How about
systems with multiple racks of storage or storage with multiple LUNs, or
exceptionally large LUNs with 35+ Partitions? Are you sure 56 ticks is
enough... I don't think so.

Even then a sleep... is a terrible hack. Though it is used gratuitously
in many places, mostly in bad places to "trick" the said programmer into
thinking it is "F1X3d". I am not slamming anyone here, just the
practice.

Though I am declaratively an "non-programmer" (I only deal with Hardware
and Networks)... maybe this is a good enough reason to change that
though.
-- 
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster:  Linux
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Acknowledgement sent to Donovan Baarda <abo@minkirri.apana.org.au>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #32 received at 273182@bugs.debian.org (full text, mbox):

From: Donovan Baarda <abo@minkirri.apana.org.au>
To: 273182@bugs.debian.org
Cc: greg@gregfolkert.net
Subject: Bug#273182: udev doesn't create /dev/md* in time for mdadm-raid to start them. All sw-raid filesys fail to mount.
Date: Tue, 12 Apr 2005 00:11:07 +1000
responding to the web archive here... apologies for bad quoting.

> This is entirely unsatisfactory, adding lines
> to /etc/modules? /etc/modules is deprecated and should not be around if
> you are using modprobe, hotplug, discover..et-al. This is just bad
> advice or workaround.

Deprecated or not, /etc/modules is still the earliest possible place to
load modules, short of compiling them into the kernel. As I said, the
order of discover and hotplug could be re-arranged so they are early
enough to load modules for mdadm-raid, but then many other things may
need to be re-arranged.

Also, /etc/modules is also the only place to explicitly load modules not
detected or miss-detected by the autodetect tools... for this reason I
suspect it will never go away.

> Wow this is great, tell us to use a file which explicitly has this as
> its header:
>
>    # This file does not exist. Please do not ask the debian maintainer about it.
>    # You may use it to do strange and wonderful things, at your risk.
>
> So you propose to have this fugly hack in a Production system? (later
> when Sarge is released. I'd like to think not.

Yeah, I read that. I suspect it is the udev maintainer in denial that
the features that it provides are really needed. The reality is, udev
must create the md0 devices. The md module doesn't notify it that they
need to be created. This is the best way I know udev can be told to
create device nodes.
        
> Ouch, 3 seconds on relatively small systems might just work. How about
> systems with multiple racks of storage or storage with multiple LUNs, or
> exceptionally large LUNs with 35+ Partitions? Are you sure 56 ticks is
> enough... I don't think so.
>
> Even then a sleep... is a terrible hack. Though it is used gratuitously
> in many places, mostly in bad places to "trick" the said programmer into
> thinking it is "F1X3d". I am not slamming anyone here, just the
> practice.

Yeah, its a hack. The real solution should probably be;

"modeprobe <blah>" does not complete until device <blah> is loaded and
ready to be used. In this case, modeprobe should interact some how with
udev and not terminate until udev has created the device nodes.

However, I'm not sure modprobe can do that easily... I dunno how the
kernel/modprobe/udev interactions work, but I have a feeling modprobe
cannot easily ask udev when it is finished.

On a system with bucket-loads of partitions this means modprobe could
take ages. But even if modprobe didn't wait for udev, anything that
wanted to mount those partitions would still have to wait for udev.
Unless udev can be made faster, it will probably prove to be unusable on
such systems.

-- 
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Message #35 received at 273182@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: 273182@bugs.debian.org, 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: a possible fix/workaround
Date: Sat, 21 May 2005 16:12:14 +0200
[Message part 1 (text/plain, inline)]
Thanks to Marco d'Itri's followup to #294404, I have implemented
a fix to the problem that mdadm and udev don't like each other. It
is a slighly modified version from Marco's suggestion. Patch
attached.

The idea is that mdadm checks whether /dev/md0 or /dev/md/0 is
present and if not, that it creates it with MAKEDEV. If /dev/.udevdb
is a directory, it first exports WRITE_ON_UDEV to make MAKEDEV
actually write to /dev and not to /dev/.static/dev.

I have also undone vorlon's changes and added some code to ensure
that mdadm-raid gets called at S25 instead of S04. Separate patch
attached. Vorlon's patch included a change to config.c (see [0])
which I cannot figure out. Do you know what problem it tries to
solve? He describes it as:

  "tweaks mdadm --scan's behavior to prefer the in-kernel device
  names as listed in /proc/partitions if these are present as device
  nodes on the filesystem."

0. http://bugs.debian.org/cgi-bin/bugreport.cgi/mdadm-294404.diff?bug=294404&msg=60&att=1

This works so far. Now a new problem has arisen, which I am
investigating (gdb downloading right now). The device nodes are
properly created during the boot phase *before* mdadm is run.
However, mdadm fails to run with the -s flag:

  debian:/dev# mdadm -A -s
  md: md0 stopped.
  mdadm: no devices found for /dev/md0
  debian:/dev# ls -l /dev/md0
  brw-rw----  1 root disk 9, 0 2005-05-21 11:02 /dev/md0
  debian:/dev/# cat /etc/mdadm/mdadm.conf
  DEVICE partitions
  ARRAY /dev/md0 level=raid1 num-devices=2 UUID=68a1895a:3cae93a0:35e3b385:eb38616f
    devices=/dev/sda2,/dev/sda3

device nodes for /dev/sda{2,3} exist and /proc/partitions knows
about these partitions too.

Assembling the device manually works:

  debian:/dev# mdadm -A /dev/md0 /dev/sda[23]
  [...]

Note that /dev/md0 does not change (m/c time remain unchanged).
Since vorlon said that this is not surprising as the kernel would
actually register the device when called without -s, I tried to
remove the /dev/md0 device node: this causes the above command to
fail.

So, to recap:

  - device nodes are being created at the right point in time
  - manual assembly of raid devices works
  - automated assembly using /etc/mdadm/mdadm.conf does not work

Let's go, gdb.

Relevant straces:
  http://madduck.net/~madduck/scratch/mdadm.strace.bz2
  http://madduck.net/~madduck/scratch/mdadm-manual.strace.bz2

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
man muss noch chaos in sich haben
um einen tanzenden stern zu gebähren.
                                                -- friedrich nietzsche
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Message #38 received at 273182@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: 273182@bugs.debian.org, 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: Re: a possible fix/workaround
Date: Sat, 21 May 2005 16:17:32 +0200
[Message part 1 (text/plain, inline)]
also sprach martin f krafft <madduck@debian.org> [2005.05.21.1612 +0200]:
> Patch attached.

There must be a cure for this crap. Now they are attached.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"never underestimate the bandwidth of
 a station wagon full of tapes careening down the highway."
                                                -- andrew s. tanenbaum
[mdadm-01-revert_vorlon.patch (text/plain, attachment)]
[mdadm-02-marco-suggestion.patch (text/plain, attachment)]
[mdadm-99-nmu.patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#273182; Package kernel-source-2.6.8. Full text and rfc822 format available.

Message #41 received at 273182@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: 273182@bugs.debian.org, 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: Re: a possible fix/workaround
Date: Sat, 21 May 2005 17:35:48 +0200
[Message part 1 (text/plain, inline)]
severity 273182 critical
merge 273182 294404
tags 294404 = patch confirmed pending
tags 301560 = patch confirmed pending
thanks

Okay, Steve's config.c patch in addition to Marco's suggestion
appear to solve this bug. Attached is the final patch for an NMU.

I have tested this only on VMware (but with SCSI, so modules are
being used, but via initrd), and not using a RAID-on-root. Anyway,
RAID-on-root pivot happens way before init, so it would not make
a difference anyway (and RAID-on-root just won't work for now).

I will now post a testers-sought message to debian-devel so that we
can verify that the three bugs are fixed. NMU packages are available
from

  deb http://debian.madduck.net ~madduck/packages/nmu/mdadm/
  deb-src http://debian.madduck.net ~madduck/packages/nmu/mdadm/

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
your eyes are weary from staring at the CRT. you feel sleepy. notice
how restful it is to watch the cursor blink. close your eyes. the
opinions stated above are yours. you cannot imagine why you ever felt
otherwise.
[mdadm-1.9.0-2.2.NMU.patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Severity set to `critical'. Request was from martin f krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `kernel-source-2.6.8' to `mdadm'. Request was from martin f.krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `critical'. Request was from martin f.krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 273182 294404. Request was from martin f.krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Mario Joussen <joussen@debian.org>:
Bug#273182; Package mdadm. Full text and rfc822 format available.

Acknowledgement sent to Erik van Konijnenburg <ekonijn@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Mario Joussen <joussen@debian.org>. Full text and rfc822 format available.

Message #54 received at 273182@bugs.debian.org (full text, mbox):

From: Erik van Konijnenburg <ekonijn@xs4all.nl>
To: martin f krafft <madduck@debian.org>, 273182@bugs.debian.org
Cc: 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: Re: Bug#273182: a possible fix/workaround
Date: Sat, 21 May 2005 19:17:21 +0200
On Sat, May 21, 2005 at 05:35:48PM +0200, martin f krafft wrote:
> -	    echo "Starting raid devices: "
> +      if [ -d /dev/.udevdb -a ! -e /dev/md0 -a ! -e /dev/md/0 ]; then
> +        echo -n "Creating raid device nodes: "
> +        cd /dev && WRITE_ON_UDEV=1 ./MAKEDEV md
> +        echo "done."
> +      fi
> +      echo -n "Starting raid devices: "

I suspect this will not work if /dev/md0 is activated by the initrd,
and the user wants to mount /dev/md7 which is not touched by initrd.
At the moment, I can't test suspicion, so please feel free to ignore the
following ramblings if testers are happy.

Mdadm is of course perfectly capable of creating it's own /dev/md0,
provided auto=md is given for the relevant device in /etc/mdadm/mdadm.conf.

The problem is that users are not aware that this configuration option
exists, giving rise to repeated bug reports, so you want to create the
device regardless of config setting.

Mdadm provides the --auto commandline option for that, but it turns out
that the absense of auto=md in the config file overrules the command line,
so it's useless in practice.

The attached patch changes this, so that --auto works regardless of command
line settings, like so:

	# rm /dev/md0
	rm: cannot remove `/dev/md0': No such file or directory
	# cat /etc/mdadm/mdadm.conf
	DEVICE partitions
	ARRAY /dev/md0 level=raid1 num-devices=2 UUID=85318365:3b91c827:faee55c7:b1d96199
	# /sbin/mdadm -A -s -a
	mdadm: error opening /dev/md0: No such file or directory
	# ./mdadm -A -s -a
	mdadm: /dev/md0 has been started with 2 drives.
	# ls -l /dev/md0
	brw-------  1 root root 9, 0 2005-05-21 19:06 /dev/md0
	#

With this modification, you no longer need the tests for /dev/.udevdb etc,
and can simply say $MDADM -A -s -a in /etc/init.d/mdadm-raid.

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 18:45:04.000000000 +0200
@@ -732,7 +732,7 @@
 					devlist->devname);
 				rv |= 1;
 			} else {
-				mdfd = open_mddev(devlist->devname, array_ident->autof);
+				mdfd = open_mddev(devlist->devname, (autof ? autof : array_ident->autof));
 				if (mdfd < 0)
 					rv |= 1;
 				else {
@@ -759,7 +759,7 @@
 					rv |= 1;
 					continue;
 				}
-				mdfd = open_mddev(dv->devname, array_ident->autof);
+				mdfd = open_mddev(dv->devname, (autof ? autof : array_ident->autof));
 				if (mdfd < 0) {
 					rv |= 1;
 					continue;
@@ -777,7 +777,7 @@
 			} 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, (autof ? autof : array_list->autof));
 					if (mdfd < 0) {
 						rv |= 1;
 						continue;



Information forwarded to debian-bugs-dist@lists.debian.org, Mario Joussen <joussen@debian.org>:
Bug#273182; Package mdadm. Full text and rfc822 format available.

Message #57 received at 273182@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: Erik van Konijnenburg <ekonijn@xs4all.nl>
Cc: 273182@bugs.debian.org, 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: Re: Bug#273182: a possible fix/workaround
Date: Sat, 21 May 2005 19:29:55 +0200
[Message part 1 (text/plain, inline)]
also sprach Erik van Konijnenburg <ekonijn@xs4all.nl> [2005.05.21.1917 +0200]:
> > -	    echo "Starting raid devices: "
> > +      if [ -d /dev/.udevdb -a ! -e /dev/md0 -a ! -e /dev/md/0 ]; then
> > +        echo -n "Creating raid device nodes: "
> > +        cd /dev && WRITE_ON_UDEV=1 ./MAKEDEV md
> > +        echo "done."
> > +      fi
> > +      echo -n "Starting raid devices: "
> 
> I suspect this will not work if /dev/md0 is activated by the initrd,
> and the user wants to mount /dev/md7 which is not touched by initrd.
> At the moment, I can't test suspicion, so please feel free to ignore the
> following ramblings if testers are happy.

What makes you suspicious? Whether the initrd has created device
nodes or not, the above should just create all the missing ones
for minors 0 through 15.

> The attached patch changes this, so that --auto works regardless of command
> line settings, like so:

This is of course a much nicer solution. I am indifferent as to
which one is preferable, given the closeness to the release.

I do want to note that your patch could be improved further, but we
need some discussion about how to do this:

> -				mdfd = open_mddev(devlist->devname, array_ident->autof);
> +				mdfd = open_mddev(devlist->devname, (autof ? autof : array_ident->autof));

so if auto=mdp appears in the config, and --auto=md is passed, which
one should take priority? Right now, the command line option does
so.

Isn't --auto=yes intended to enable this but read the actual setting
from the configuration file? I am not sure that your patch still
allows this.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"anyone who is capable of getting themselves made president
 should on no account be allowed to do the job"
                                                      -- douglas adams
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Mario Joussen <joussen@debian.org>:
Bug#273182; Package mdadm. Full text and rfc822 format available.

Acknowledgement sent to Erik van Konijnenburg <ekonijn@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Mario Joussen <joussen@debian.org>. Full text and rfc822 format available.

Message #62 received at 273182@bugs.debian.org (full text, mbox):

From: Erik van Konijnenburg <ekonijn@xs4all.nl>
To: martin f krafft <madduck@debian.org>
Cc: 273182@bugs.debian.org, 294404@bugs.debian.org, 301560-quiet@bugs.debian.org
Subject: Re: Bug#273182: a possible fix/workaround
Date: Sat, 21 May 2005 19:57:01 +0200
On Sat, May 21, 2005 at 07:29:55PM +0200, martin f krafft wrote:
> also sprach Erik van Konijnenburg <ekonijn@xs4all.nl> [2005.05.21.1917 +0200]:
> > > -	    echo "Starting raid devices: "
> > > +      if [ -d /dev/.udevdb -a ! -e /dev/md0 -a ! -e /dev/md/0 ]; then
> > > +        echo -n "Creating raid device nodes: "
> > > +        cd /dev && WRITE_ON_UDEV=1 ./MAKEDEV md
> > > +        echo "done."
> > > +      fi
> > > +      echo -n "Starting raid devices: "
> > 
> > I suspect this will not work if /dev/md0 is activated by the initrd,
> > and the user wants to mount /dev/md7 which is not touched by initrd.
> > At the moment, I can't test suspicion, so please feel free to ignore the
> > following ramblings if testers are happy.
> 
> What makes you suspicious? Whether the initrd has created device
> nodes or not, the above should just create all the missing ones
> for minors 0 through 15.

What happens is the following:

* initrd creates devices needed for boot: root and swap, /boot is omitted.
* these devices become visible in sysfs
* after pivotroot, udevstart walks /sys at S04, and feeds /sys/block/md0
  to udev; udev creates /dev/md0.
* at S40 or so, you come along, see that /dev/md0 exists, and decide
  not to do MAKEDEV
* now we don't have /dev/md7, and mdadm fails.
* (unless you're an LVM user, but that's another story)

> > The attached patch changes this, so that --auto works regardless of command
> > line settings, like so:
> 
> This is of course a much nicer solution. I am indifferent as to
> which one is preferable, given the closeness to the release.

Understood.  I'm not a Debian maintainer, so none of the release pressure
is on me; if you don't have room to work on this option, the alternative
is fine with me.  This patch is intended as a fallback in case your
earlier upload does not make it through testing.

As a worst case scenario, you can degrade the bug to wishlist and claim
that users should do the auto thing in the config file.

> I do want to note that your patch could be improved further, but we
> need some discussion about how to do this:
> 
> > -				mdfd = open_mddev(devlist->devname, array_ident->autof);
> > +				mdfd = open_mddev(devlist->devname, (autof ? autof : array_ident->autof));
> 
> so if auto=mdp appears in the config, and --auto=md is passed, which
> one should take priority? Right now, the command line option does
> so.
> 
> Isn't --auto=yes intended to enable this but read the actual setting
> from the configuration file? I am not sure that your patch still
> allows this.

You're right that we should look at this, for now that's completely
untested in this patch.

I'll dive in and see if I can find out what's supposed to happen.

Regards,
Erik




Merged 273182 294404 310126. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `normal'. Request was from martin f.krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 273182 284028 294404 310126. Request was from martin f.krafft <madduck@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `critical'. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed Request was from madduck@debian.org (martin f. krafft) to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed Request was from madduck@debian.org (martin f. krafft) to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed Request was from madduck@debian.org (martin f. krafft) to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed Request was from madduck@debian.org (martin f. krafft) to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to martin f krafft <madduck@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Greg Folkert <greg@wamgr.com>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #83 received at 273182-done@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: 273182-done@bugs.debian.org, 284028-done@bugs.debian.org, 294404-done@bugs.debian.org, 310126-done@bugs.debian.org, 301560-done@bugs.debian.org
Subject: Acknowledging NMUs
Date: Wed, 25 May 2005 16:38:37 +0200
[Message part 1 (text/plain, inline)]
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.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"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
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 06:48:08 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.