Bug 610889 - update device-mapper to >= 1.02.48 in Fedora 12 and 13 because of pam_mount recommendation
Summary: update device-mapper to >= 1.02.48 in Fedora 12 and 13 because of pam_mount r...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 610925 622385
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-02 16:56 UTC by Till Maas
Modified: 2010-08-17 11:30 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-17 11:30:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Till Maas 2010-07-02 16:56:36 UTC
Description of problem:

pam_mount recommends to use device-mapper >= 1.02.48, because it fixes a race condition. Unluckily F13 only has 1.02.44 and F12 1.02.38. Is it possible to update device-mapper on F12 or F13?

Comment 1 Alasdair Kergon 2010-07-02 17:01:21 UTC
Can you be more specific about which fix it needs?
This is what changed in 1.02.48:

Version 1.02.48 - 17th May 2010
================================
  Use -d to control level of messages sent to syslog by dmeventd.
  Change -d to -f to run dmeventd in foreground.
  Do not print encryption key in message debug output (cryptsetup luksResume).
  Fix dmeventd static build library dependencies.
  Fix udev flags on remove in create_and_load error path.


But yes, we should probably do updates regardless of the reason.

Comment 2 Till Maas 2010-07-02 17:16:13 UTC
(In reply to comment #1)
> Can you be more specific about which fix it needs?
> This is what changed in 1.02.48:
> 
> Version 1.02.48 - 17th May 2010
> ================================

>   Fix udev flags on remove in create_and_load error path.

I guess it is the udev change. This is probably what made the pam_mount author recommend 1.02.48, because he reported this cryptsetup bug:
http://code.google.com/p/cryptsetup/issues/detail?id=73#c1

Comment 3 Milan Broz 2010-07-02 17:27:34 UTC
These udev problems are also dependent on kernel, I think update od devicemapper in F12 is not needed.

For F13 I am not surem probably we should update it there...

Anyway, cryptsetup should work with all versions of devicemapper library.

Comment 4 Alasdair Kergon 2010-07-02 17:34:56 UTC
So maybe good for F13, but certainly unnecessary for F12.

However, it's easiest if we keep the versions all in line, so let's go for 2.02.70 / 1.02.52 next week which is intended to be a stable version.

Comment 5 Peter Rajnoha 2010-07-02 18:37:05 UTC
Well, first we need the version of udev that does not remove existing udev database at its initialisation in F13 (that's one line change in /sbin/start_udev, shouldn't be a problem) + support for import{db} udev rule (udev >= 152). These changes are in rawhide, but not yet in F13.

I'll clone bug #603724 for Harald to do a new build there, then we need to add that particular Requires: udev >= ...

Comment 6 Peter Rajnoha 2010-07-02 18:46:11 UTC
Udev update request filed against F13 - bug #610925.

Comment 7 Peter Rajnoha 2010-07-02 19:03:46 UTC
(..other packages may not be prepared for this change - there were a few problems there, so we have udev support enabled in F13 and later. I wouldn't risk enabling udev there.. :))

Comment 8 Peter Rajnoha 2010-07-02 19:05:06 UTC
(In reply to comment #7)
> (..other packages may not be prepared for this change - there were a few
> problems there..

..in F12, I mean.

Comment 9 Milan Broz 2010-08-17 10:48:18 UTC
I think pam_mount+cryptsetup is already updated, closing this bug.

Comment 10 Till Maas 2010-08-17 10:58:12 UTC
(In reply to comment #9)
> I think pam_mount+cryptsetup is already updated, closing this bug.

But this bug is about device-mapper.

Comment 11 Milan Broz 2010-08-17 11:11:32 UTC
why do you need need update device-mapper now?

Recommendation for pam bmount is because of cryptsetup and udev support usptream.

btw in F12 is already updated and F13 is waiting for bug 622385.

Comment 12 Till Maas 2010-08-17 11:30:26 UTC
(In reply to comment #11)

> btw in F12 is already updated and F13 is waiting for bug 622385.

If the update will hit F13 eventually and this is tracked somehow else, then everything is fine with me. It would have helped to mention the update here in the bug report.


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