From: Moshe Yudkowsky <msha5_17@bl.com>
To: linux-hotplug@vger.kernel.org
Subject: 2.6.14, 2.6.15 md mystery partially solved (was: 2.6.15: mdrun, udev
Date: Mon, 06 Mar 2006 04:10:11 +0000 [thread overview]
Message-ID: <440BB623.30507@bl.com> (raw)
Last month, I posted about the a mystery: I could not boot into 2.6.15
when using RAID. As of yesterday I found that I couldn't boot into
2.6.14 any more, either -- right now I'm back on 2.6.12. At the time the
theory was that udev and md were in some sort of race condition.
The lack of 2.6.14 boot motivated me to see if I could solve the 2.6.15
problem.
Part of the mystery is solved: someone -- I have to assume it was a
prank -- renamed the md module the "md-mod" module. Therefore it never
showed up in the boot image. My mind boggles at the thought of renaming
the module without warning and without catching it during depmod. Oh,
and another gotcha: "mdadm --auto" doesn't create the /dev/md directory;
you have to do it yourself. A bit of missing documentation there. (Sorry
if I sound a bit bitter, but renaming the module retrospectively? It's
a major gotcha.)
Other problems, however, persist in 2.6.15: the standard script "mdrun"
tries to create a /dev/md/0 even though I don't have an array by that
name. I created a custom hook and custom script which uses
/etc/mdamd.conf to create the correct devices. As a side benefit of
these custom scripts, which use "mdadm --auto", I don't get the the
create dozens of /dev/md* entries created by the standard "mdrun."
Unfortunately I get a kernel panic when I try to boot the 2.6.15 image,
for unknown reasons; I can't even tell where the problem occurs just
yet. But as sad as that may be, at least this "md" problem turns out not
to be a udev problem.
I'd send the partial solution off to the Debian developers, but for the
life of me I can't figure out who should get the solution.
So thanks to everyone who commented during the previous thread!
--
Moshe Yudkowsky
work: http://www.Disaggregate.com
book: http://www.PebbleAndAvalanche.com
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2006-03-06 4:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 4:10 Moshe Yudkowsky [this message]
2006-03-06 17:00 ` 2.6.14, 2.6.15 md mystery partially solved (was: 2.6.15: mdrun, Moshe Yudkowsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=440BB623.30507@bl.com \
--to=msha5_17@bl.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).