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 dlehman. +++ 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 self.setScreen () AttributeError: 'NoneType' object has no attribute 'name' <snip> --- Additional comment from dlehman 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 awilliam 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 lvm-devel as of Friday, 8-Oct-2010.
Usespace part of bug #64176.
Sigh. Typo:-) Usespace part of bug #641476.
Ah - tracked down the thread on *dm*-devel here: http://www.redhat.com/archives/dm-devel/2010-October/msg00020.html
Presumably the priority of this is not really 'low' if you're considering it to be an accepted blocker? What's the deadline? (The linked F14Blocker bug doesn't give any indication.)
(In reply to comment #5) > Ah - tracked down the thread on *dm*-devel here: > > http://www.redhat.com/archives/dm-devel/2010-October/msg00020.html Well that is the kernel portion. But last I spoke to Peter he said he had posted an LVM2 userspace patch to lvm-devel too. I'm not seeing it, maybe it got caught in a non-subscriber filter? If not then we need to get back with Peter.
Ah, scrap that. Yes, it was trapped and it's here: http://www.redhat.com/archives/lvm-devel/2010-October/msg00070.html I just wanted to be sure the bugzillas track the right versions of the patches.
The F14 devel schedule (http://poelstra.fedorapeople.org/schedules/f-14/f-14-devel-tasks.html) says that the final change deadline is 18 October.
alasdair: use of the 'priority' field in Fedora is discretionary and down to the development team of the component in question. I believe Anaconda team doesn't actually use the field to prioritize their work so they simply leave it at the default value for all bugs, which is 'low'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #6) > Presumably the priority of this is not really 'low' if you're considering it to > be an accepted blocker? What's the deadline? (The linked F14Blocker bug > doesn't give any indication.) This needs to be patched, built, tested and available by Monday (Oct 18). In order to hit this milestone, I recommend having a fix available for testing on Friday.
I've fixed a few small things (add new flag to ioctl debug message, don't attempt to rename the device in the filesystem when the name didn't actually change but only the uuid did, don't allow the v1 ioctl to proceed if this flag is given, reset the flag if someone abuses the interface and sets the name after the uuid was set). I'm currently adding the 'dmsetup' support, as we require that all significant library functionality is exposed through dmsetup (so that it is easily tested/debugged).
(In reply to comment #12) > I've fixed a few small things (add new flag to ioctl debug message, don't > attempt to rename the device in the filesystem when the name didn't actually > change but only the uuid did, don't allow the v1 ioctl to proceed if this flag > is given, reset the flag if someone abuses the interface and sets the name > after the uuid was set). I'm currently adding the 'dmsetup' support, as we > require that all significant library functionality is exposed through dmsetup > (so that it is easily tested/debugged). That's great news, thanks for the update. As you know, the change deadline for Fedora 14 is Oct 18 (monday). To feel comfortable with any late changes and to reduce possible delays, we really need to have things lined up by tomorrow. Thanks for your efforts!
Patch checked in upstream. Needs a little testing then we can put it into f14 as, say, lvm2-2_02_75-support-uuid-rename.patch. http://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=5426e85284b63d8d871179501f9cfe44d65f7df9
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 https://fedoraproject.org/wiki/BugZappers
we need a build including this fix to be submitted to koji and bodhi today in order to avoid slipping the release, folks - thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
seems like there is a build in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=200666 but it needs to be submitted to bodhi. agk or pjones, please take care of that, thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
pjones is going to submit all these related packages as a single update when they are all ready
https://admin.fedoraproject.org/updates/lvm2-2.02.73-3.fc14
Pushed stable.