mdadm: created as /dev/md0, becomes /dev/md127 after reboot.

Bug #964052 reported by Jason S. Wagner
54
This bug affects 11 people
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

-- lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04
--

-- apt-cache policy mdadm
mdadm:
  Installed: 3.2.3-2ubuntu1
  Candidate: 3.2.3-2ubuntu1
  Version table:
 *** 3.2.3-2ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
--

-- Environment
Ubuntu 12.04 Server Edition 64bit (installed from the 20120323 daily ISO)
Installed into a guest running on VirtualBox 4.1.10, hosted on Windows 7.
Disk configuration:
1 SATA controller
1 20GB HDD (used at / mount point)
5x 512MB HDD (used to simulate RAID5 array)
--

-- What action I took
On an untouched installation, I install mdadm, and attempt to create a RAID5 array with this command:

sudo mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

After confirming that I wanted to create the array, mdadm reported success. I initialized a file system on it, mounted it, and created a simple text file containing 'Hello World' on it. Then, I reboot.
--

-- What I expected to happen
mdadm would reassemble the array at boot time as /dev/md0.
--

-- What happened instead
mdadm reassemled the array at boot time as /dev/md127.
--

It took a great deal if hunting around to discover that the array had actually been assembled. I forget what command I issued that finally tipped me off to the existence of the assembled array, but running 'sudo mdadm --detail /dev/md127' confirmed that it was the array I had just built. I mounted the array and viewed the contents of the text file to confirm.

This did not occur when I built my array on my test and production servers running Ubuntu 10.04 Server 64bit, so I am calling this new and unexpected behavior, and filing it as a bug.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: mdadm 3.2.3-2ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
CurrentDmesg:

Date: Sat Mar 24 11:05:07 2012
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120323)
MDadmExamine.dev.sda: Error: command ['/sbin/mdadm', '-E', '/dev/sda'] failed with exit code 1: mdadm: cannot open /dev/sda: Permission denied
MDadmExamine.dev.sda1: Error: command ['/sbin/mdadm', '-E', '/dev/sda1'] failed with exit code 1: mdadm: cannot open /dev/sda1: Permission denied
MDadmExamine.dev.sda2: Error: command ['/sbin/mdadm', '-E', '/dev/sda2'] failed with exit code 1: mdadm: cannot open /dev/sda2: Permission denied
MDadmExamine.dev.sda5: Error: command ['/sbin/mdadm', '-E', '/dev/sda5'] failed with exit code 1: mdadm: cannot open /dev/sda5: Permission denied
MDadmExamine.dev.sdb: Error: command ['/sbin/mdadm', '-E', '/dev/sdb'] failed with exit code 1: mdadm: cannot open /dev/sdb: Permission denied
MDadmExamine.dev.sdc: Error: command ['/sbin/mdadm', '-E', '/dev/sdc'] failed with exit code 1: mdadm: cannot open /dev/sdc: Permission denied
MDadmExamine.dev.sdd: Error: command ['/sbin/mdadm', '-E', '/dev/sdd'] failed with exit code 1: mdadm: cannot open /dev/sdd: Permission denied
MDadmExamine.dev.sde: Error: command ['/sbin/mdadm', '-E', '/dev/sde'] failed with exit code 1: mdadm: cannot open /dev/sde: Permission denied
MDadmExamine.dev.sdf: Error: command ['/sbin/mdadm', '-E', '/dev/sdf'] failed with exit code 1: mdadm: cannot open /dev/sdf: Permission denied
MachineType: innotek GmbH VirtualBox
ProcEnviron:
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-20-generic root=/dev/mapper/hostname-root ro
SourcePackage: mdadm
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH
etc.blkid.tab: Error: [Errno 2] No such file or directory: '/etc/blkid.tab'

Revision history for this message
Jason S. Wagner (jasonswagner) wrote :
Revision history for this message
Jason S. Wagner (jasonswagner) wrote :

'mdadm.conf.txt' shows some manually made changes I was attempting to follow after reading this thread:
http://ubuntuforums.org/showpost.php?s=b6e090eae70ded837a35d33a855bf21b&p=11623570&postcount=22

However, the alterations have no effect on the end result. mdadm still reassembles the array as /dev/md127, which is undesirable.

Revision history for this message
Jason S. Wagner (jasonswagner) wrote :

Reinstalling from the same ISO, I used guided partitioning to completely wipe the root partition and reinstall the system. At the same time, I also told it to mount the array.

After installation, my array is mounted and I see this in /etc/fstab:

# /media/raid was on /dev/md0 during installation
UUID=c3cc60a8-e441-4c68-a59d-ee6bacaf1e34 /media/raid ext4 defaults 0 2

Sure enough, the array is now assembled as /dev/md0. Of course, I shouldn't have to do that when I told mdadm that I wanted the array to be /dev/md0 in the first place.

Revision history for this message
Jason S. Wagner (jasonswagner) wrote :

I had a question in IRC (#ubuntu+1) about what the untouched mdadm.conf looked like after building the array but before I altered it. To undo the changes I made, simply remove the commented and uncommented "DEVICE" lines.

Again, this change had no visible effect on how the array was reassembled.

Jorge Castro (jorge)
Changed in mdadm (Ubuntu):
status: New → Confirmed
Revision history for this message
Thiago Martins (martinx) wrote :

This bug is still present on Ubuntu 14.04...

Revision history for this message
TJ (tj) wrote :

I dealt with this issue recently and initially looked at it as a bug, but having explored it some more, I have come to the conclusion that it is not - it is by design, and for a purpose.

During early userspace when the initrd.img's /init shell script is running mdadm is triggered. It examines /etc/mdadm/mdadm.conf (in the initrd.img) for ARRAY entries and will assemble those, but it will also assemble other arrays it finds that are not defined in the conf file.

Since arrays defined using ARRAY usually have device numbers starting at 0, the dynamically discovered arrays are numbered starting at 127 to avoid them using the device number of MD devices defined and assembled later when Upstart has taken over.

With an entry in the root file-sytem's /etc/mdadm/mdadm.conf of, for example:

ARRAY /dev/md0 UUID=...

the update-intramfs hook scripts installed by mdadm will copy that into the initrd when it is built and the device will receive its correct designation.

Revision history for this message
Jason S. Wagner (jasonswagner) wrote :

I moved this machine to Arch long ago, but my mdadm array still exists and is still /dev/md127. Arch never used Upstart and is on systemd. I don't know if this is helpful or not, but again, since it's originally assembled as /dev/md0 and later becomes /dev/md127, and that previous versions of mdadm assembled the array as /dev/md0, it seems like a bug.

All this said, I don't know what the purpose of discussing it here is since it's clearly not specific to Ubuntu, and I don't know that anyone has reported this upstream.

Revision history for this message
Tony Middleton (ximera) wrote :

I have seen this behaviour a number of times on Ubuntu and Debian.

After you create the array you need to update mdadm.conf. However, this is not enough as you also need to update the version in initrd.img. This might happen automatically if you subsequently do some updates. I find the easiest way to force it is to call

dpkg-reconfigure mdadm

Scott Moser (smoser)
Changed in mdadm (Ubuntu):
importance: Undecided → Medium
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.