Red Hat Bugzilla – Bug 641476
devicemapper UUID field cannot be assigned after map creation
Last modified: 2013-09-02 02:51:38 EDT
In order to properly resolve an issue originally discovered in bug#584328, a fix to kernel and lvm2 is also required. Please see below for details from firstname.lastname@example.org.
+++ This bug was initially created as a clone of Bug #584328 +++
The following was filed automatically by anaconda:
anaconda 13.37.2 exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/iw/partition_gui.py", line 1066, in populate
devstring = device.name
File "/usr/lib/anaconda/iw/partition_gui.py", line 1836, in getScreen
self.populate(initial = 1)
File "/usr/lib/anaconda/gui.py", line 1393, in setScreen
new_screen = self.currentWindow.getScreen(anaconda)
File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked
AttributeError: 'NoneType' object has no attribute 'name'
--- Additional comment from email@example.com on 2010-10-08 13:36:31 EDT ---
pjones is working on a patch to the kernel (device-mapper) to allow setting of uuid for already-existing maps, as long as they have no uuid at that time.
Patches will also be required for libdevmapper to provide a function along the lines of the existing function dm_task_set_newname, but for uuid instead of name. I have drafted a patch to pyblock that will make use of all of the above to ensure correct uuids are set for dmraid and mpath devices created by pyblock.
--- Additional comment from firstname.lastname@example.org on 2010-10-08 14:16:10 EDT ---
At the 2010-10-08 blocker meeting we agreed to reassign this bug to pyblock and create new bugs against kernel and libdevmapper which block this bug. Jlaska will be doing this.
Please note, this bug is on the dependency chain as blocking the release of F14 blocker. Please help resolve this issue as quickly as possible.
A patch has been posted to dm-devel as of Friday, 8-Oct-2010, and has been updated a couple of times since then.
Seems Alasdair said on dm-devel that he will accept the kernel patch the "old way", assigning to him.
This seems to be the proposed patch for me to review:
FYI, as seen in bug 641474: "The F14 devel schedule
that the final change deadline is 18 October." Thanks for your prompt attention!
Should be fixed in 126.96.36.199-42
kernel-188.8.131.52-43.fc14 has been submitted as an update for Fedora 14.
Patch reviewed and accepted into the upstream device-mapper queue for 2.6.37. I have done some refactoring, but there is no difference of any significance to its functionality.
Peter Rajnoha tested this thoroughly this morning and was able to make the dm remove ioctl hang. A one-line fix to the patch is required.
Discussed at the 2010-10-15 blocker review meeting. pjones is working on this whole set of bugs and expects it to be cleaned up today.
Fedora Bugzappers volunteer triage team
kernel-184.108.40.206-43.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #11)
> kernel-220.127.116.11-43.fc14 has been pushed to the Fedora 14 stable repository. If
> problems still persist, please make note of it in this bug report.
Moving into ON_QA as an updated kernel is available with the fix.
That kernel is in stable now.