Bug 817064

Summary: RFE: blivet should not do anything harmful devices during storage.devicetree.populate() and storage.reset().
Product: [Fedora] Fedora Reporter: Jan Safranek <jsafrane>
Component: python-blivetAssignee: David Lehman <dlehman>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint-list, bcl, dlehman, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-12 10:36:52 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:

Description Jan Safranek 2012-04-27 14:47:05 UTC
I use pyanaconda.storage as a library to manage local storage and storage.devicetree.populate() deactivates my MD array.

IMHO there should be some flag, which would switch Anaconda to  'application mode' (from 'installer mode') and it would not modify things unless the application really wants so.

I.e. storage.devicetree.populate in the 'application mode' would just scan current state of the system, without modifying it.

Comment 1 Jan Safranek 2012-12-20 14:56:59 UTC
Related to this is also Anaconda's hard probing - if I destroy an array (mdadm -S), Anaconda still finds its metadata on the disk and tries to do weird magic to it, resulting in MDRAIDArrayDevice in the storage tree.

IMHO, simple udev scan could be enough. If udev tells there is no /dev/mdX, then anaconda should not create it, even it finds metadata for it on some block devices.

Comment 2 David Lehman 2012-12-20 16:07:06 UTC
(In reply to comment #1)
> Related to this is also Anaconda's hard probing - if I destroy an array
> (mdadm -S), Anaconda still finds its metadata on the disk and tries to do
> weird magic to it, resulting in MDRAIDArrayDevice in the storage tree.

mdadm -S does not destroy an array -- it deactivates the array. That is why the metadata is still there, any therefore anaconda starts it because at installation time that's the obvious thing to do. Most likely blivet will not automatically activate devices unless it is in OS installation mode.

> 
> IMHO, simple udev scan could be enough. If udev tells there is no /dev/mdX,
> then anaconda should not create it, even it finds metadata for it on some
> block devices.

For non-OS-installation mode, this is probably what the behavior will be.

Comment 3 Jan Safranek 2013-01-18 15:45:46 UTC
I also noticed today that devicetree.populate() removes any swap from the system, that's quite dangerous.

All I need in 'application mode' is (quick!) udev scan without any hard probing, mounting, unmounting or system modification.

Comment 4 Jan Safranek 2013-01-24 15:16:32 UTC
I stumbled upon another traceback, now in storage.reset(). If I have a logical volume mounted somewhere, I get:

>>> storage.reset()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 440, in reset
    self.roots = findExistingInstallations(self.devicetree)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 3187, in findExistingInstallations
    device.teardown()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 757, in teardown
    self._teardown(recursive=recursive)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 2548, in _teardown
    lvm.lvdeactivate(self.vg.name, self._name)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicelibs/lvm.py", line 411, in lvdeactivate
    raise LVMError("lvdeactivate failed for %s: %s" % (lv_name, msg))
pyanaconda.storage.errors.LVMError: lvdeactivate failed for test: running lvm lvchange -a n --config  devices { filter=["r|/loop0$|","r|/loop1$|","r|/loop2$|","r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|"] }  test/test failed


If the logical volume is *not* mounted, reset() works.

Comment 5 David Lehman 2013-02-05 23:20:04 UTC
This should be fixed by commit f98464e851b9ac5.

Comment 6 Jan Safranek 2013-04-12 10:36:52 UTC
python-blivet-0.10 it not harmful anymore, still reset() is quite slow.