Re: understanding mdraid initialization logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Trying to guess ...

On Tue, Feb 15, 2011 at 2:43 PM, Gerd v. Egidy <lists@xxxxxxxx> wrote:
> Hi,
>
> I'm trying to understand what goals dracut wants to reach regarding mdraids -
> what should the status of the mdraids be when dracut is finished?
>
> Currently I see that when dracut includes an mdadm.conf, all these mds will
> stay active when dracut ends. When dracut does not use/include an mdadm.conf,
> the mds will be deactivated again at the end of dracut unless they are needed
> for the root filesystem.
>
> This logic is in modules.d/90mdraid/parse-md.sh, it is done by conditionally
> deleting the mdraid-cleanup.sh.
>
> What is the reason for deactivating the mds? Why is this handled differently
> when an mdadm.conf is present?
>

mdadm.conf is present only if you build initrd in hostonly mode - i.e.
when you include only modules that are needed for currently running
hardware. In this case it can be assumed that all arrays are actually
present and used by currently booting system.

If mdadm.conf is not present, it is generic image. In this case you
can't be sure that all arrays actually belong to and will be activated
by booting system. So they are stopped to avoid confusion.

> I need an dracut image which is portable across a lot of machines so I can't
> include an mdadm.conf. But when the real system starts after dracut is done,
> all mds except the root one are gone and can't be mounted through fstab. I use
> filesystem labels in fstab, so the md numbers are irrelevant.
>

Well, usually system is expected to boot without initrd as well, so it
should be capable of activating those resources itself. I wonder what
distro are you using?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux