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-blivet | Assignee: | David Lehman <dlehman> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | 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
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. (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. 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. 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.
This should be fixed by commit f98464e851b9ac5. python-blivet-0.10 it not harmful anymore, still reset() is quite slow. |