Saturday, 22 February 2014

Re: Dmraid to Mdadm migration

Hello Patrick,

Here are some questions i received in private, but i think is worth
replying to the mailing list.

On 22 February 2014 03:30, Patrick H. <> wrote:
> Is there support for dmraid5? Can I test this on an alpha build? Is the
> project page in github or launchpad.

Ubuntu is a distribution and dmraid and mdadm are packages of thereof.
So patches for all the work so far are uploaded into Ubuntu Archive. 1.0.0.rc16-4.2ubuntu3 or better 3.2.5-5ubuntu3 or better

> I have been using dmraid since 10.04 or before. It's been a few years that I
> have been running the same Intel Matrix Raid5 with the optional raid45
> kernel module. I want to test this migration from dmraid to mdadm before the
> 14.04 release comes out.

Note that above dmraid package drops usage of raid45 module, and
instead uses stock and widely available dm-raid modules.

If you wish to try out mdadm, you'll need to install mdadm package
i've linked above, comment out /etc/default/grub.d/dmraid2mdadm.cfg,
update references to correct devices as per original email and update



> On Fri, Feb 21, 2014 at 8:57 PM, Steve Langasek <>
> wrote:
>> Hi Dimitri,
>> On Thu, Feb 20, 2014 at 03:49:28PM +0000, Dimitri John Ledkov wrote:
>> > This cycle a few things were done in mdadm & dmraid packages to
>> > prepare for transition from dmraid to mdadm for a few formats that
>> > mdadm supports.
>> > At the moment it trusty, mdadm has full support to assemble Intel
>> > Matrix Raid and DDF fakeraid arrays, instead of dmraid. At the moment
>> > however, mdadm codepath is disable via a kernel cmdline options
>> > (nomdmonddf nomdmonisw) and thus if both mdadm and dmraid are present
>> > in the initramfs dmraid will complete assembly. With or without kernel
>> > options, dmraid completes assembly if mdadm is not present. Thus
>> > existing upgrades continue to work as they are.
>> > However to complete the upgrade, i would like remove the feature flag
>> > and enable mdadm based assembly, such that installing mdadm migrates
>> > systems using dmraid for Intel Matrix Raid and DDF fakeraids to mdadm.
>> > But further changes are required, as the device names change when
>> > moving from dmraid to mdadm, e.g.:
>> > dmraid names:
>> > * /dev/mapper/isw_cbhjgfachh_Volume1
>> > * /dev/mapper/isw_cbhjgfachh_Volume1p1
>> > * /dev/mapper/isw_cbhjgfachh_Volume1p2
>> > * /dev/mapper/isw_cbhjgfachh_Volume1p3
>> > become under mdadm:
>> > * /dev/md/Volume1
>> > * /dev/md/Volume1p1
>> > * /dev/md/Volume1p2
>> > * /dev/md/Volume1p3
>> > Thus changes to /etc/fstab, and/or bootloader are required to look for
>> > new places.
>> > The question I have, is whether such migration should be done
>> > automatically or left in the hands of the administrator (e.g. if mdadm
>> > is not installed, dist-upgrade is performed no changes are required
>> > and dmraid is continued to be used. If one installs mdadm, one would
>> > also need to either disable mdadm-fakeraid assembly with kernel
>> > cmdline options or adjust /etc/fstab & grub for the new names).
>> I think we should definitely prefer such migration to be handled
>> automatically.
>> Have a look at the linux-base package in Debian: the postinst has been
>> dropped from the Ubuntu package, but in Debian this is the package which
>> handled the migration from /dev/hda to UUIDs. It's the logical place to
>> insert other device name migrations, though it clearly would need some
>> updating for new bootloader packages (FSVO "new" that includes "grub2" ;).
>> Perhaps since this migration is specific to dmraid and mdadm it would make
>> sense to move the migration code to mdadm itself, but hopefully this at
>> least makes for a good starting point.
>> Hope that helps,
>> --
>> Steve Langasek Give me a lever long enough and a Free OS
>> Debian Developer to set it on, and I can move the world.
>> Ubuntu Developer
>> --
>> ubuntu-devel mailing list
>> Modify settings or unsubscribe at:

ubuntu-devel mailing list
Modify settings or unsubscribe at: