Bug 817064 - RFE: blivet should not do anything harmful devices during storage.devicetree.populate() and storage.reset().
RFE: blivet should not do anything harmful devices during storage.devicetree....
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-27 10:47 EDT by Jan Safranek
Modified: 2013-04-12 06:36 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-12 06:36:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Safranek 2012-04-27 10:47:05 EDT
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 09:56:59 EST
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 11:07:06 EST
(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 10:45:46 EST
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 10:16:32 EST
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 18:20:04 EST
This should be fixed by commit f98464e851b9ac5.
Comment 6 Jan Safranek 2013-04-12 06:36:52 EDT
python-blivet-0.10 it not harmful anymore, still reset() is quite slow.

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