From: Nix <nix@esperi.org.uk>
To: Dan Christensen <jdc@uwo.ca>
Cc: linux-raid@vger.kernel.org
Subject: Re: naming of md devices
Date: Sat, 25 Mar 2006 01:52:53 +0000 [thread overview]
Message-ID: <87hd5nnvd6.fsf@hades.wkstn.nix> (raw)
In-Reply-To: <87fyl9swxb.fsf@uwo.ca> (Dan Christensen's message of "23 Mar 2006 02:44:19 -0000")
On 23 Mar 2006, Dan Christensen moaned:
> To answer myself, the boot parameter raid=noautodetect is supposed
> to turn off autodetection. However, it doesn't seem to have an
> effect with Debian's 2.6.16 kernel. It does disable autodetection
> for my self-compiled kernel, but since that kernel has no initrd or
> initramfs, it gets stuck at that point. [If I understand correctly,
> you can't use mdadm for building the array without an initrd/ramfs.]
That's true if your root filesystem is on RAID.
> I also tried putting root=LABEL=/ on my boot command line. Debian's
> kernel seemed to understand this but gave:
>
> Begin: Waiting for root filesystem...
> Done.
> Done.
> Begin: Mounting root filesystem
> ...kernel autodetection of raid seemed to happen here...
> ALERT /dev/disk/by_label// does not exist
Ah, welcome to the udev problems. Look at the Debian kernel-maint list
at lists.debian.org and marvel at the trouble they're having because
they're using udev on their initramfs. I'm glad I used mdev instead :)
>> Will the Debian kernel/initramfs fall
>> back to using mdadm to build the arrays?
`Fall back to'? If autodetection is turned off, it's not a fallback,
it's the common case.
>> the above is on unstable... i don't use stable (and stable definitely does
>> the wrong thing --
>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338200>).
>
> That bug is against initrd-tools, which is a different package I
> believe.
Yes, it is unmaintained.
> BUT, my self-compiled kernel is now failing to bring up the arrays! I
> didn't change anything on the arrays or on this kernel's boot line,
> and I have not turned off kernel auto-detection, so I have no idea why
> there is a problem. Unfortunately, I don't have a serial console, and
> the kernel panics so I can't scroll back to see the relevant part of
> the screen. My self-compiled kernel has everything needed for
> my root filesystem compiled in, so I avoided needing an initramfs.
Without boot messages it's very hard to say what's going on. If you have
another machine, you could try booting with the messages going over a
serial console...
--
`Come now, you should know that whenever you plan the duration of your
unplanned downtime, you should add in padding for random management
freakouts.'
next prev parent reply other threads:[~2006-03-25 1:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-22 17:39 naming of md devices Dan Christensen
2006-03-23 1:35 ` Nix
2006-03-23 2:07 ` dean gaudet
2006-03-23 2:37 ` Daniel Pittman
2006-03-25 1:53 ` Nix
2006-03-23 2:43 ` Dan Christensen
2006-03-25 1:52 ` Nix [this message]
2006-03-26 19:34 ` Dan Christensen
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=87hd5nnvd6.fsf@hades.wkstn.nix \
--to=nix@esperi.org.uk \
--cc=jdc@uwo.ca \
--cc=linux-raid@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).