Bug 1275354

Created attachment 1086548 [details]
anaconda log

anaconda log

Seems "/dev/md126" created using cli command  is stored wrongly as  "/dev/md/126 by the installer . At install select installer searches "/dev/md/126" and throws An exception " IOException: Could not stat device /dev/md/126 - No such file or directory
as shown in the below exception trace

------------------------------------------------------------------------
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 872, in clearPartitions
    self.initializeDisk(disk)

  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 911, in initializeDisk
    labelType = _platform.bestDiskLabelType(disk)

  File "/usr/lib/python2.7/site-packages/blivet/platform.py", line 128, in bestDiskLabelType
    parted_device = parted.Device(path=device.path)

  File "/usr/lib64/python2.7/site-packages/parted/decorators.py", line 41, in new
    ret = fn(*args, **kwds)

  File "/usr/lib64/python2.7/site-packages/parted/device.py", line 54, in __init__
    self.__device = _ped.device_get(path)

IOException: Could not stat device /dev/md/126 - No such file or directory.
---------------------------------------------------------------------------

Did you rescan the disks after making your changes?

Please attach all of the logs from /tmp/*log as individual text/plain attachments.

You have to give the new array/VD a name, like this:

  mdadm -C -l1 -n2 --metadata=1.2 /dev/md/vdisk1 /dev/sda /dev/sdb

And you may need to either reboot or tell the installer to rescan storage after creating the array.

(In reply to David Lehman from comment #5)
> You have to give the new array/VD a name, like this:
> 
>   mdadm -C -l1 -n2 --metadata=1.2 /dev/md/vdisk1 /dev/sda /dev/sdb
> 
> And you may need to either reboot or tell the installer to rescan storage
> after creating the array.


David ,

 We generally use "/dev/md127" and not "/dev/md/127" while creating 

When I quickly searched I found the same in the below link
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-raid.html

Please let me know is this because of any change in design . In that case
is it documented ?

The v1.2 metadata format supports persistent names. This format most probably did not exist when the document you referenced was written (2010 or so), but it is now the default for new arrays. Think of the equivalent situation for device-mapper and lvm: would you choose you create a new logical volume with a name like 'dm-3' when you could instead use 'root' or 'home'? This change in the installer was not documented because it is only relevant in very rare cases like yours. If you simply reboot after creating the array you will not see this issue, which is due to an odd inconsistency in the mdadm tool (see bug 1083641).

(In reply to David Lehman from comment #7)
> The v1.2 metadata format supports persistent names. This format most
> probably did not exist when the document you referenced was written (2010 or
> so), but it is now the default for new arrays. Think of the equivalent
> situation for device-mapper and lvm: would you choose you create a new
> logical volume with a name like 'dm-3' when you could instead use 'root' or
> 'home'? This change in the installer was not documented because it is only
> relevant in very rare cases like yours. If you simply reboot after creating
> the array you will not see this issue, which is due to an odd inconsistency
> in the mdadm tool (see bug 1083641).

David,
We can close this bug.

Closing per comment #8.  Feel free to change the exact resolution if you don't feel like it reflects what actually happened here.  Thanks!