Bug 207474 - Dynamically linked lvm utilities seg faults leaving broken initrd images
Summary: Dynamically linked lvm utilities seg faults leaving broken initrd images
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-21 11:37 UTC by Roy-Magne Mo
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version: 2.02.17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-10 18:33:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tarred down /etc/lvm directory (5.83 KB, application/x-gzip)
2006-09-21 11:37 UTC, Roy-Magne Mo
no flags Details

Description Roy-Magne Mo 2006-09-21 11:37:14 UTC
Description of problem:
Dynamically linked tools from the lvm2 packages segfaults, possibly due to
linked in libraries that has been updated. lvm.static works 

Version-Release number of selected component (if applicable):
2.02.01-1.2.1

How reproducible:
always

Steps to Reproduce:
1. lvdisplay 
2.
3.
  
Actual results:
segfault from all the normal utilities and lvm.static works as normal.

Expected results:


Additional info:

related libraries:
# rpm -q device-mapper libselinux ncurses 
device-mapper-1.02.07-2.0
libselinux-1.30.3-4.fc5
ncurses-5.5-19

I'm attachming my lvm.conf and a backtrace from a segfaulting binary, is there
any other information that would be helpful?

(gdb) run
Starting program: /usr/sbin/lvdisplay 
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x721000
File descriptor 3 left open
File descriptor 4 left open
File descriptor 5 left open

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0807304e in dev_create_file (filename=0x8cddfd0 "/etc/lvm/lvm.conf",
dev=0x0, alias=0x8ce2010, use_malloc=1) at device/dev-cache.c:70
#2  0x080728ce in read_config_file (cft=0x8cddfb8) at config/config.c:237
#3  0x0806f7a3 in _load_config_file (cmd=0x8cd8e90, tag=0x80b55d3 "") at
commands/toolcontext.c:347
#4  0x0806fa3f in _init_lvm_conf (cmd=0x8cd8e90) at commands/toolcontext.c:377
#5  0x08070474 in create_toolcontext (the_args=0x80c5760) at
commands/toolcontext.c:927
#6  0x0805734c in lvm2_main (argc=1, argv=0xbf8a2bc4, is_static=0) at
lvmcmdline.c:954
#7  0x0806b3ea in main (argc=0, argv=0x11) at lvm.c:20

Comment 1 Roy-Magne Mo 2006-09-21 11:37:14 UTC
Created attachment 136846 [details]
tarred down /etc/lvm directory

Comment 2 Roy-Magne Mo 2006-09-21 12:00:38 UTC
selinux is not enabled on this server btw

Comment 3 Alasdair Kergon 2006-09-21 13:34:19 UTC
I think you've got fc4 and fc5 packages mixed up.

fc5 contains device-mapper-1.02.02-3.2 and lvm2-2.02.01-1.2.1

fc4 contains device-mapper-1.02.07-2.0 and lvm2-2.02.06-1.0.fc4

(There's evidently a missing 'conflicts' line in the fc4 dm package which should
have stopped you updating dm without also updating lvm2.)

Comment 4 Roy-Magne Mo 2006-09-21 13:46:19 UTC
Seems to be the culprit, i downgraded to the version from FC5 - and it works
agains :) I will try to reinstall the newer kernels to see if those boots now. 

So I guess the fix is to update the packages in FC5 and push them out? 

It seems this manifested itself as a problem with some laters updates, so I
guess there is a lot of installs out there which has gone the yum upgrade path
from FC4 to FC5 with this situation.

Comment 5 Roy-Magne Mo 2006-09-21 15:16:48 UTC
the FC5 packages generates the correct initrd

Comment 6 Rakotomandimby Mihamina 2006-12-06 09:30:13 UTC
FC5 is:

[root@mainty ~]# rpm -aq | grep device-mapper
device-mapper-1.02.02-3.2
[root@mainty ~]# rpm -aq | grep lvm
lvm2-2.02.01-1.2.1

I stil hang with a "soft lockup detected on CPU#0".

Kernel 2.6.18-1.2239
I have to revert to older kernel (2.6.15) to have a working system.


Comment 7 Alasdair Kergon 2007-01-10 18:33:24 UTC
new fc5 package updates on their way that should fix the numbering


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