[Bug 1054948] Re: dmraid broken for large drives

[Dmitrijs Ledkovs]

On 24 September 2012 11:09, Jan Kleinsorge <jan.kleinsorge at gmail.com> wrote:
> But wouldn't that simply only imply that dmraid and mdadm are not supposed to co-exist? I'm a bit puzzled about this change. As far as I understand this, the auto-assemble rules have been removed just to guarantee the function of dmraid - temporarily or not.

They should. As one may have both dmraid & mdadm arrays (none of which
are isms) and possibly dmraid & mdadm & isms arrays (managed by either
dmraid / mdadm). I do agree that we should now default to mdadm when
dealing with isms raid arrays, but we need (i) not break existing
dmraid isms arrays (ii) co-existing with dmraid managed isms raid
arrays (optionally) (iii) default to mdadm for isms.

Server, net-install and alternative installer images have both dmraid
& mdadm. Desktop CDs have dmraid. It was planned for this cycle for
Desktop CDs to also have mdadm, but this is now post-poned to
R-series.

> Automated installation procedure aside, it is currently not possible to remove dmraid and add mdadm to get an imsm 1.3 (external metadata) running out of the box, right? If no dmraid is present, the cut-down of mdadm does not seem necessary.
>

No, it is not currently not possible, as most likely the system will
fail-to boot out of the box due to lack of initramfs integration for
isms arrays.

> It seems this can also be user-fixed without jumping through many hoops
> by restoring previous rules, right?
>

(a) include mdmon in initramfs
(b) grab upstream mdadm.udev rules and drop them into
/etc/udev/rules.d/ with same file name as the one in
/lib/udev/rules.d/
(c) remove dmraid

update-initramfs and attempt to reboot =)
keep dmraid capable initramfs as a backup.

> >From my perspective it then boils down to the problem that, even if
> auto-assembly would be enabled, mdadm currently does not support the
> root being member of the array itself. As I mentioned in 1028677, mdmon
> is missing in the initrd which prohibts the any assembly at that point.
> The effect is that mdadm sets of read-only devices, instead of auto-
> read-only. With adding mdmon this boots but during shutdown the array
> seems to be taken down too early so the system does not finish that
> gracefully. There have been attempts to fix this in debian (1054773).
> See also [1].
>

Yes, yes, yes, yes, yes.

I am planning on reviewing patches proposed in Debian for inclusion in
Ubuntu. In particular I'd like to include mdmon in the initramfs as
well as add the hooks to shutdown cleaner.

It would be nice to include mdmon in the initramfs conditionally, if
isms/ddf are detected.

The next step would be to see if isms-capable mdadm can co-exist with
dmraid. If yes, all is great. If not, I would be considering
alternative routes, e.g. patching out isms support out of dmraid =/
but that looks ugly.

The other concern is that unfortunately I do not have isms hardware
available so I cannot test this myself =(
I'm busy adding LVM support to ubiquity right now. But I will
hopefully look into all of this towards the end of the week.

Regards,

Dmitrijs.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mdadm in Ubuntu.
https://bugs.launchpad.net/bugs/1054948

Title:
  dmraid broken for large drives

Status in “mdadm” package in Ubuntu:
  New

Bug description:
  Attempting to set up a fresh Quantal system on a system with Intel 'fakeraid' (imsm, 1.3) and 3TB SATA RAID1. When running the live CD, dmraid identifies the drives as being of size 746GB (Same effect with a Windows 7 setup without loading the corresponding Intel drivers prior to partitioning). 
  dmraid -an does not release the mappings. The work-around for the installation is to boot with nodmraid, install mdadm and assemble manually prior to starting the installation. dmraid seems to be severly broken for a pretty much standard PC setup. 
  mdadm can handle Intel imsm firmware-backed RAID just fine. 

  After installation, several measures still have to be taken when the system /root is also part of that array/. See #1054773 and references for major issues regarding this.
   
  SInce mdadm is actively supported by Intel and dmraid is at best in a maintenance state, deprecation of dmraid in favor of mdadm would be welcome.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1054948/+subscriptions