[->UUIDudev] mdadm.conf without ARRAY definition breaks reboot of new arrays

Bug #532960 reported by douby
This bug affects 2 people
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
In Progress
Surbhi Palande

Bug Description

Binary package hint: mdadm

I'm using 2 computers with full update karmic and they had both the same problem.

I created my array : raid5 of 4 disks.
I checked in the /proc/mdstat, the array was ok. (sync) (sda,sdb,sdc,sdd on md0)
I created a logical volume with lvm on the top of my array, using all the space (pv: md0, vg: /dev/storage, lv:/dev/storage/1TORAID5ARRAY).
I formated the partition as ext3.
At this time, I could mount the partition on /media/raid
I decided to reboot a this time (the sync wasn't finished) and when i went back to the system, I saw that my array was broken.

My array md0 wasn't in /proc/mdstat but there was a md_d0 array only on sdb (???)
On lvm, the pv was changed and was on /dev/sdb (???)

I could solve my problem in stopping /dev/md_d0, modifying /etc/mdadm.conf, reassembling the array and reconfiguring my pv.
In /etc/mdadm.conf, I used the array disk id instead of something like that :
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1

Now, when I reboot, the system is ok.

I think that mdadm would be more flexible if it use id of device instead of /dev/sdx in default/automatic config...

Revision history for this message
ceg (ceg) wrote :

What did you use? Here (9.10) the alternate installer created mdadm.conf with lines like these

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=...

(no member device names)

Revision history for this message
ceg (ceg) wrote :

Wait, you created the arrays by hand, mdadm --create does not put anything in mdadm.conf and you are experiencing:

Bug #136252 [->UUIDudev] mdadm.conf w/o ARRAY lines but udev/mdadm not assembling arrays. (boot fails)
Bug #550131 initramfs missing /var/run/mdadm dir (loosing state)

ceg (ceg)
summary: - mdadm, not using uid of the array breaks after a reboot of a new install
+ [->UUIDudev] mdadm, not using uid of the array breaks after a reboot of
+ a new install
ceg (ceg)
summary: - [->UUIDudev] mdadm, not using uid of the array breaks after a reboot of
- a new install
+ [->UUIDudev] mdadm.conf without ARRAY definition breaks reboot new
+ arrays
summary: - [->UUIDudev] mdadm.conf without ARRAY definition breaks reboot new
+ [->UUIDudev] mdadm.conf without ARRAY definition breaks reboot of new
Surbhi Palande (csurbhi)
Changed in mdadm (Ubuntu):
status: New → Confirmed
Revision history for this message
Surbhi Palande (csurbhi) wrote :
Download full text (5.3 KiB)

Call for testing mdadm 2.7.1 autoassembly - for any one who is seeing this bug.

For hitherto Ubuntu releases the mdadm package shall stay at 2.7.1 However Natty would have mdadm at 3.4.1. This document is intended to test the mdadm fixes for 2.7.1. Here is the rough procedure that needs to be followed:

Testing auto-assembly of your md array when your rootfs lies on it:
1)Install the mdadm package and initramfs package kept at: https://edge.launchpad.net/~csurbhi/+archive/mdadm-autoassembly
2)Run /usr/share/mdadm/mkconf and ensure that your /etc/mdadm/mdadm.conf has the array definition.
a) Save your original initramfs in /boot itself by say /boot/initrd-old.img.
b) Then run update-initramfs -c -k <your-kernel-version>. Store this iniramfs as /boot/initrd-new.img. We shall use this initramfs as a safety net. If you cannot boot with the auto-assembly fixes, then you should not land in a foot in your mouth situation. Through grub's edit menu, you can then resort to this safety net by editing the initrd=initrd-new.img (or if this does not work for some random reason then resort back to your older initrd=initrd-old.img) This way you will be sure that you can still boot your precious system.
c) Now comment or remove the ARRAY definitions from your /etc/mdadm/mdadm.conf and once again run the same “update-initramfs -c -k <your-kernel-version>” to generate a brand new initramfs.
3)Run mdadm –detail –scan and note the UUIDs in the array. Note the hostname stored in your array. Does it not match with your real hostname? Then we can fix that at the initramfs prompt that you inevitably will land at if you try auto-assembly. Also note the device components that form the root md-device. Keep this paper for cross checking when you reboot
5)If you are at the initramfs prompt here are the things that you should first ensure:
a) ls /bin/hostname /etc/hostname - are these files present?
b) run “hostname”. Does this show you the hostname that your system is intended to have? Is it the same as the contents of /etc/hostname.
c) ls /var/run – Is this dir there?
If you answer yes to the above three questions, then things are so far so good. Now run the following command:
mdadm –assemble -U uuid /dev/<md-name> <dev-components-listed here>
Your mdadm –detail –scan that you ran previously should have given you the component names if you dont know it right now. Hopefully you have them listed on your paper.
Eg in my case I ran:
mdadm –assemble -U uuid /dev/md0 /dev/sda1 /dev/sdb1
Again run:
mdadm –detail –scan <md-device> and verify that the uuids are indeed updated and the hostname reflects the hostname that is stored /etc/hostname. You can now press Ctr+D and you should come back to the root prompt. However you still need to test auto-assembly of your root md device. To do that simple reboot and you should not see the face of initramfs this time. You should land gently on your root prompt as you expected. If you do not see the light of the rootfs prompt this way or using this initramfs, then as mentioned earlier, please avail your saved initrd images through grub. Skip the further steps in this case. Update the launchpad bugs, sa...


Changed in mdadm (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Surbhi Palande (csurbhi)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.