Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux General Discussion (http://www.linux-archive.org/archlinux-general-discussion/)
-   -   mkinitcpio: mdadm_udev Hook (http://www.linux-archive.org/archlinux-general-discussion/709313-mkinitcpio-mdadm_udev-hook.html)

Simon Perry 10-03-2012 12:41 PM

mkinitcpio: mdadm_udev Hook
 
Hi,

I've just been re-installing a box, and saw that the wiki says regarding
using the mdadm_udev hook:

> "This is the preferred method of mdadm assembly (rather than using the
> above mdadm hook). "

I've tried to use the mdadm_udev hook, but the devices get named:

> normal md0 (/boot) is md127
> normal md1 (encrypted, then lvm with swap and / on it ) is md126

I found this out with "cat /proc/partitions" once my box failed to boot
and dropped to the initramfs shell.

Seems pretty random, the first actual device isn't even the lowest
number.

There doesn't seem to be any documented way to have my raid1 devices
named so I can use:

> cryptdevice=/dev/md1:crypt

in my kernel arg line.

The only way to get things to work is to use the mdadm hook and have my
devices specified in /etc/mdadm.conf

Can I rely on md127 and md126 being the same across every boot, and
therefore resign myself to using this numbering (instead of the much
nicer md0 and md1), and use it in my cryptdevice kernel arg and be done
with it?

Given this thread: https://bbs.archlinux.org/viewtopic.php?id=149358

And the comment:

"I have little interest in supporting the mdadm hook. Assembly via udev
is the preferred method here."

What is the right way to do this?

Cheers.

--
Simon Perry (aka Pezz)

Thomas Bächler 10-03-2012 01:44 PM

mkinitcpio: mdadm_udev Hook
 
Am 03.10.2012 14:41, schrieb Simon Perry:
> Hi,
>
> I've just been re-installing a box, and saw that the wiki says regarding
> using the mdadm_udev hook:
>
>> "This is the preferred method of mdadm assembly (rather than using the
>> above mdadm hook). "
>
> I've tried to use the mdadm_udev hook, but the devices get named:
>
>> normal md0 (/boot) is md127
>> normal md1 (encrypted, then lvm with swap and / on it ) is md126
>
> I found this out with "cat /proc/partitions" once my box failed to boot
> and dropped to the initramfs shell.
>
> Seems pretty random, the first actual device isn't even the lowest
> number.

You need to create a file /etc/mdadm.conf. mdadm --examine --scan will
generate the right lines for you. This file will be added to the
initramfs and your names will be fine again.

Simon Perry 10-03-2012 08:07 PM

mkinitcpio: mdadm_udev Hook
 
On 03/10/12, Thomas Bächler wrote:

| You need to create a file /etc/mdadm.conf. mdadm --examine --scan will
| generate the right lines for you. This file will be added to the
| initramfs and your names will be fine again.

Yep, that's what I've done, and I've used the mdadm hook as I have in the
past.

Based on the mkinitcpio wiki page, and the forum post, I'm under the
impression that using mdadm_udev to auto-assemble the arrays is what I
should be using (and is what will be supported in the future).

The mdadm_udev hook does work as advertised, but I don't see how I can
use it when I need a known /dev/mdx device for use in something like a
"cryptdevice=" kernel arg.

Cheers.

--
Simon Perry (aka Pezz)

Thomas Bächler 10-03-2012 09:17 PM

mkinitcpio: mdadm_udev Hook
 
Am 03.10.2012 22:07, schrieb Simon Perry:
> Based on the mkinitcpio wiki page, and the forum post, I'm under the
> impression that using mdadm_udev to auto-assemble the arrays is what I
> should be using (and is what will be supported in the future).
>
> The mdadm_udev hook does work as advertised, but I don't see how I can
> use it when I need a known /dev/mdx device for use in something like a
> "cryptdevice=" kernel arg.

First of all, once you add the mdadm.conf file, the mdX names will
follow the naming usual scheme - the md126+ names will only be used when
the array is not mentioned in mdadm.conf.

Second, you can always use /dev/disk/by-uuid/.

Dave Reisner 10-03-2012 10:01 PM

mkinitcpio: mdadm_udev Hook
 
> On 03/10/12, Thomas B?chler wrote:
>
>> You need to create a file /etc/mdadm.conf. mdadm --examine --scan will
>> generate the right lines for you. This file will be added to the
>> initramfs and your names will be fine again.
>
> Yep, that's what I've done, and I've used the mdadm hook as I have in
> the
> past.
>
> Based on the mkinitcpio wiki page, and the forum post, I'm under the
> impression that using mdadm_udev to auto-assemble the arrays is what I
> should be using (and is what will be supported in the future).
>
> The mdadm_udev hook does work as advertised, but I don't see how I can
> use it when I need a known /dev/mdx device for use in something like a
> "cryptdevice=" kernel arg.

Thomas is pointing out that the mdadm_udev hook will (should?) still
honor your /etc/mdadm.conf if it has ARRAY decls in it (you'll see it
being picked up on the mkinitcpio run if this is true). If that isn't
happening, or it isn't being honored, we should find out why.

Alternatively, cryptdevice understands tags, e.g:

cryptdevice=UUID=46c78135-8ac0-4928-8b26-5d23a77b1ff1:cryptrewt

Of course, since there isn't a filesystem involved, UUID is the only one
that makes sense for MBR disks. PARTUUID is also supported, and
PARTLABEL support will be available in the next mkinitcpio release.

Cheers,
Dave

Simon Perry 10-03-2012 10:25 PM

mkinitcpio: mdadm_udev Hook
 
On 03/10/12, Thomas Bächler wrote:

| First of all, once you add the mdadm.conf file, the mdX names will
| follow the naming usual scheme - the md126+ names will only be used when
| the array is not mentioned in mdadm.conf.
|
| Second, you can always use /dev/disk/by-uuid/.

Cool, makes sense, and damn me for not going one step further and
setting up mdadm.conf before giving up and going back to the mdadm hook.

:)

-> Running build hook: [mdadm_udev]
Custom /etc/mdadm.conf file will be used in initramfs for assembling
arrays.

Cheers for the info fellas.

--
Simon Perry (aka Pezz)


All times are GMT. The time now is 03:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.