[Bug 1054948] Re: dmraid broken for large drives

[Brian Candler]

As an experiment, I did the following:

* rebuild /sbin/mdadm and /sbin/mdmon from source, install in /sbin
* vi /usr/share/initramfs-tools/hooks/mdadm
    - add "copy_exec /sbin/mdmon /sbin"
* vi /lib/udev/rules.d/64-md-raid.rules
    - ENV{ID_FS_TYPE}=="ddf_raid_member|isw_raid_member|linux_raid_member", GOTO="md_inc"
    - ACTION=="add", RUN+="/sbin/mdadm --incremental $tempnode --offroot"
* /usr/share/mdadm/mkconf >/etc/mdadm/mdadm.conf
* apt-get remove dmraid; apt-get autoremove
* vi /etc/fstab, set root to be /dev/md/Volume0p1
* reboot and set root=/dev/md/Volume0p1 on the command line

It did actually come up, with /dev/md125p1 as the root filesystem; cat
/proc/mdstat showed it resyncing.

However there were a number of problems:

(1) the following messages at boot time

mdadm: CREATE user root not found
mdadm: CREATE group disk not found

(2) if I try to run update-grub:

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-52-generic
Found initrd image: /boot/initrd.img-3.2.0-52-generic
/usr/sbin/grub-probe: error: no such disk.
/usr/sbin/grub-probe: error: no such disk.
...
Found linux image: /boot/vmlinuz-3.2.0-29-generic
Found initrd image: /boot/initrd.img-3.2.0-29-generic
/usr/sbin/grub-probe: error: no such disk.
/usr/sbin/grub-probe: error: no such disk.
/usr/sbin/grub-probe: error: no such disk.
Found memtest86+ image: /boot/memtest86+.bin
done

(2a) A later reboot showed the kernel command line had root=/dev/md125p1
- which works, however I would have preferred the more persistent
/dev/md/Volume0p1 since the md device numbers are prone to renumbering.

(3) @sbin/mdmon is still running, which suggests that the initramfs
instance hasn't been replaced (--takeover)

(4) reboot hung at this point:

 * Stopping MD monitoring service mdadm --monitor  [ OK ]
 * Asking all remaining processes to terminate  [ OK ]
 * All processes ended within 5 seconds....  [ OK ]
<< wait >>
[ 1324.030873] INFO: task jbd2/md125p1-8:765 blocked for more than 120 seconds.
[ 1324.030957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1324.031222] INFO: task dd:5714 blocked for more than 120 seconds.
[ 1324.031298] "echo 0 >/proc/sys/kernel/hung_task_timeout_secs" disables this message.
<< wait >>
[ 1444.030497] INFO: task jbd2/md125p1-8:765 blocked ... etc
[ 1444.030807] INFO: task flush-9:125:2405 blocked ... etc
[ 1444.031243] INFO: task dd:5714 blocked ... etc

and it needed a hard reset. But after the hard reset, it did come up OK,
and md125 was still in sync.

(5) obviously, any local changes to /sbin/mdadm, /sbin/mdmon or config
files will be lost if the packages are updated

So I'd say this approach is not something to recommend for production
use yet, but if it makes it to 14.04 LTS that would be great.

I also tried reverting all the changes listed at the top of this
message, to turn it back into dmraid. That worked, although on first
boot I had to give the full root=/dev/mapper/isw_XXXXXXXXXX_Volume0p1
parameter on the kernel command line (to replace root=/dev/md125p1).
After this, "update-grub" worked as usual, and subsequent reboots didn't
hang.

-- 
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