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 http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
