Bug 1150174 - Exception on initialization with stopped MD RAID.
Summary: Exception on initialization with stopped MD RAID.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: 22
Hardware: Unspecified
OS: All
unspecified
high
Target Milestone: ---
Assignee: mulhern
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-07 14:56 UTC by Jan Safranek
Modified: 2015-06-23 15:17 UTC (History)
5 users (show)

Fixed In Version: python-blivet-0.66-1
Clone Of:
Environment:
Last Closed: 2015-06-23 15:17:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
reproducer (766 bytes, text/plain)
2014-10-07 14:56 UTC, Jan Safranek
no flags Details
blivet log (60.30 KB, text/plain)
2014-10-07 14:57 UTC, Jan Safranek
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.