naming of md devices

naming of md devices

[Dan Christensen]

I currently use kernel autodetection of my raid devices.  I'm finding
that if I use a stock Debian kernel versus a self-compiled kernel
(2.6.15.6), the arrays md0 and md1 are switched, which creates a
problem mounting my root filesystem.

Is there a way to make the names consistent?

I'm happy to get rid of kernel autodetection and instead use
mdadm.conf.  Is this just a matter of changing the partition types?
Or a kernel boot parameter?  Will the Debian kernel/initramfs fall
back to using mdadm to build the arrays?

Thanks for any help,

Dan

Re: naming of md devices

[Nix]

On 22 Mar 2006, Dan Christensen prattled cheerily:
> I currently use kernel autodetection of my raid devices.  I'm finding
> that if I use a stock Debian kernel versus a self-compiled kernel
> (2.6.15.6), the arrays md0 and md1 are switched, which creates a
> problem mounting my root filesystem.
> 
> Is there a way to make the names consistent?

Well, you could stack LVM atop it ;)

but yes, there is. THis is my mdadm.conf:

DEVICE partitions
ARRAY /dev/md0 UUID=3a51b74f:8a759fe7:8520304c:3adbceb1
ARRAY /dev/md1 UUID=a5a6cad4:2c7fdc07:88a409b9:192ed3bf
ARRAY /dev/md2 UUID=fe44916d:a1098576:8007fb81:2ee33b5a

In fact I don't care what's mounted where because all of these that are
necessary for booting are an LVM volume group, and vgscan takes care
of everything: but if you arrange to use the mdadm.conf, you're safe.

(You can use the RAID array name, as well, but if you don't have
a name I'm not sure if you can assign a new one, while every array
always has a UUID.)

I'm not sure if there's a way to specify this on the kernel command line
when using kernel autodetection: I've never used it. (Neil? Anyone?)

> I'm happy to get rid of kernel autodetection and instead use
> mdadm.conf.  Is this just a matter of changing the partition types?
> Or a kernel boot parameter?  Will the Debian kernel/initramfs fall
> back to using mdadm to build the arrays?

Last I heard the Debian initramfs constructs RAID arrays by explicitly
specifying the devices that make them up. This is, um, a bad idea:
the first time a disk fails or your kernel renumbers them you're
in *trouble*.

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'

Re: naming of md devices

[dean gaudet]

On Thu, 23 Mar 2006, Nix wrote:

> Last I heard the Debian initramfs constructs RAID arrays by explicitly
> specifying the devices that make them up. This is, um, a bad idea:
> the first time a disk fails or your kernel renumbers them you're
> in *trouble*.

yaird seems to dtrt ... at least in unstable.  if you install yaird 
instead of initramfs-tools you get stuff like this in the initrd /init:

mknod /dev/md3 b 9 3
mdadm -Ac partitions /dev/md3 --uuid 2b3a5b77:c7b4ab81:a2b8322a:db5c4e88

initramfs-tools also appears to do something which should work... but i 
haven't tested it... it basically runs "mdrun /dev" without specifying a 
minor/uuid for the root, so it'll start all arrays... i'm afraid that 
might mess up for one of my arrays which is "auto=mdp"... and has the 
annoying property of starting arrays on disks you've moved from other 
systems.

so anyhow i lean towards yaird at the moment... (and i should submit some 
bug reports i guess).

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>).

-dean

Re: naming of md devices

[Daniel Pittman]

Nix <nix@esperi.org.uk> writes:
> On 22 Mar 2006, Dan Christensen prattled cheerily:

[...]

> Last I heard the Debian initramfs constructs RAID arrays by explicitly
> specifying the devices that make them up. This is, um, a bad idea: the
> first time a disk fails or your kernel renumbers them you're in
> *trouble*.

The initrd tool, which was the default option, does this, and it is a
bad idea.

The initramfs tool, which is mostly shared with Ubuntu, is less stupid.
It uses mdadm and a loop to scan through the devices found on the
machine and find what RAID levels are required, then builds the RAID
arrays with mdrun.

Unfortunately, it still doesn't transfer /etc/mdadm.conf to the
initramfs, resulting in arrays changing position when constructed, to my
annoyance.   So, stupid, but not as stupid as the oldest tools.

	Daniel
-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707	   email: contact@digital-infrastructure.com.au

Re: naming of md devices

[Nix]

On 23 Mar 2006, Daniel Pittman uttered the following:
> The initramfs tool, which is mostly shared with Ubuntu, is less stupid.
> It uses mdadm and a loop to scan through the devices found on the
> machine and find what RAID levels are required, then builds the RAID
> arrays with mdrun.

That's much nicer.

> Unfortunately, it still doesn't transfer /etc/mdadm.conf to the
> initramfs, resulting in arrays changing position when constructed, to my
> annoyance.   So, stupid, but not as stupid as the oldest tools.

That surely can't be hard to fix, can it?

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'

Re: naming of md devices

[Dan Christensen]

Dan Christensen writes:

> I currently use kernel autodetection of my raid devices.  I'm finding
> that if I use a stock Debian kernel versus a self-compiled kernel
> (2.6.15.6), the arrays md0 and md1 are switched, which creates a
> problem mounting my root filesystem.
> 
> Is there a way to make the names consistent?
>
> I'm happy to get rid of kernel autodetection and instead use
> mdadm.conf.  Is this just a matter of changing the partition types?
> Or a kernel boot parameter?  

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.]

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

> Will the Debian kernel/initramfs fall
> back to using mdadm to build the arrays?

dean gaudet <dean@arctic.org> writes:

> On Thu, 23 Mar 2006, Nix wrote:
>
>> Last I heard the Debian initramfs constructs RAID arrays by explicitly
>> specifying the devices that make them up. This is, um, a bad idea:
>> the first time a disk fails or your kernel renumbers them you're
>> in *trouble*.
>
> yaird seems to dtrt ... at least in unstable

I might try this, but I'm still stuck without an easy way to turn
off auto-detection.

> 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.

For now, I've just put root=/dev/md1 on the Debian kernel boot line,
and root=/dev/md0 on my self-compiled boot line.


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.

If I'm able to get my tuner card, etc working with Debian's kernel,
then I won't need my self-compiled kernel anymore, but it's
disconcerting that I now can't boot a kernel that worked fine a few
hours ago...  Any ideas what could have happened?

Thanks for the help so far!

Dan

Re: naming of md devices

[Nix]

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.'

Re: naming of md devices

[Dan Christensen]

Nix <nix@esperi.org.uk> writes:

> On 23 Mar 2006, Dan Christensen moaned:
>
>> 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 :)

Yes, I'm understanding better what is going on.  First of all, / is
not a valid label.  (The relevant thing for udev is the "safe" output
of "vol_id /dev/md1".)  So I've changed the filesystem label to "root"
using tune2fs -L.

Second, the udev in Debian had support for persistent devices for one
brief release, but it has been taken out while problems with
ide-generic are being investigated.  

I put in my own initramfs hook script to put the appropriate udev
files in the initramfs image, but still I'm not getting the
/dev/disk/by_label/root symlink.  I can't figure out why this
isn't working.

>> BUT, my self-compiled kernel is now failing to bring up the arrays! 
>
> 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...

I may try that, but the stock Debian kernel is working for me so for
now I'll probably leave this unsolved.

Sorry that this is getting a bit off topic for the list.  Thanks
for all the help!

Dan