Bug 641474 - libdm does not present method to assign UUID after map creation
libdm does not present method to assign UUID after map creation
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
14
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F14Blocker/F14FinalBlocker 584328
  Show dependency treegraph
 
Reported: 2010-10-08 15:56 EDT by James Laska
Modified: 2013-09-02 02:51 EDT (History)
16 users (show)

See Also:
Fixed In Version: 2.02.73-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-20 23:47:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description James Laska 2010-10-08 15:56:49 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 dlehman@redhat.com.

+++ 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@redhat.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 awilliam@redhat.com 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.
Comment 1 James Laska 2010-10-11 16:16:34 EDT
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.
Comment 2 Peter Jones 2010-10-11 16:30:15 EDT
A patch has been posted to lvm-devel as of Friday, 8-Oct-2010.
Comment 3 Milan Broz 2010-10-11 17:00:10 EDT
Usespace part of bug #64176.
Comment 4 Milan Broz 2010-10-11 17:01:02 EDT
Sigh. Typo:-) Usespace part of bug #641476.
Comment 5 Alasdair Kergon 2010-10-12 07:59:38 EDT
Ah - tracked down the thread on *dm*-devel here:

http://www.redhat.com/archives/dm-devel/2010-October/msg00020.html
Comment 6 Alasdair Kergon 2010-10-12 08:03:23 EDT
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.)
Comment 7 Mike Snitzer 2010-10-12 09:38:01 EDT
(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.
Comment 8 Alasdair Kergon 2010-10-12 09:45:12 EDT
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.
Comment 9 David Lehman 2010-10-12 09:56:37 EDT
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.
Comment 10 Adam Williamson 2010-10-12 16:05:37 EDT
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
Comment 11 James Laska 2010-10-13 12:23:10 EDT
(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.
Comment 12 Alasdair Kergon 2010-10-14 12:40:40 EDT
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).
Comment 13 James Laska 2010-10-14 13:22:56 EDT
(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!
Comment 14 Alasdair Kergon 2010-10-14 21:32:48 EDT
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
Comment 15 Adam Williamson 2010-10-15 12:35:26 EDT
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
Comment 16 Adam Williamson 2010-10-18 12:46:34 EDT
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
Comment 17 Adam Williamson 2010-10-18 12:50:28 EDT
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
Comment 18 Alasdair Kergon 2010-10-18 13:25:17 EDT
pjones is going to submit all these related packages as a single update when they are all ready
Comment 20 Jesse Keating 2010-10-20 23:47:36 EDT
Pushed stable.

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