Bug 1150174

Summary: Exception on initialization with stopped MD RAID.
Product: [Fedora] Fedora Reporter: Jan Safranek <jsafrane>
Component: python-blivetAssignee: mulhern <amulhern>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 22CC: amulhern, anaconda-maint-list, bcl, dlehman, vpodzime
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: All   
Whiteboard:
Fixed In Version: python-blivet-0.66-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-23 15:17:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer
none
blivet log none

Description Jan Safranek 2014-10-07 14:56:41 UTC
Created attachment 944626 [details]
reproducer

Description of problem:
b.reset() throws an exception when probing a system with stopped MD RAID.

Version-Release number of selected component (if applicable):
python-blivet-0.65-1.fc22.noarch

How reproducible:
always

Steps to Reproduce:
1. create a MD RAID and stop it:
mdadm -C -l 1 -n 2 /dev/md/test /dev/vdb{1,2}
mdadm -S /dev/md/test 

2. run attached script (it just calls Blivet.reset()

Actual results:
Traceback (most recent call last):
  File "../tools/blivet_init.py", line 27, in <module>
    b.reset()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 460, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2059, in populate
    self._populate()
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2125, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1223, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1834, in handleUdevDeviceFormat
    self.handleUdevMDMemberFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1597, in handleUdevMDMemberFormat
    md_array.updateSysfsPath()
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 764, in updateSysfsPath
    self.path)
  File "/usr/lib/python2.7/site-packages/pyudev/device.py", line 337, in from_device_file
    device_type = get_device_type(filename)
  File "/usr/lib/python2.7/site-packages/pyudev/_util.py", line 138, in get_device_type
    mode = os.stat(filename).st_mode
OSError: [Errno 2] No such file or directory: '/dev/md/test'


Expected results:
No traceback, b.mdarrays[0] shows stopped MD RAID.

Additional info:
This was working couple of versions ago, at least in python-blivet-0.61.2-2.fc21.noarch.

Comment 1 Jan Safranek 2014-10-07 14:57:54 UTC
Created attachment 944627 [details]
blivet log

Comment 2 mulhern 2014-10-07 17:48:07 UTC
Strictly speaking, this is a pyudev error, since from_device_file() is supposed to raise an EnvironmentError if the file does not exist. It's in the method header, but not the method.

However, since we can not rely on it to do the correct thing we can check for existence of file before we call from_device_file().

Comment 3 mulhern 2014-10-07 18:12:53 UTC
(In reply to mulhern from comment #2)
> Strictly speaking, this is a pyudev error, since from_device_file() is
> supposed to raise an EnvironmentError if the file does not exist. It's in
> the method header, but not the method.
> 
> However, since we can not rely on it to do the correct thing we can check
> for existence of file before we call from_device_file().

Correction: So these methods just propagate ValueErrors and EnvironmentErrors raised by the Python code (instead of raising their own DeviceNotFoundError, as they probably have some plans to do at some point). So, we had better just catch all three.

Comment 4 Jaroslav Reznik 2015-03-03 17:15:56 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22