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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1054948
Title:
dmraid broken for large drives
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1054948/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
