Bug 451816

Summary:	CMAN init script must not try to load lock_dlm
Product:	Red Hat Enterprise Linux 5	Reporter:	Robert Peterson <rpeterso>
Component:	cman	Assignee:	Robert Peterson <rpeterso>
Status:	CLOSED NOTABUG	QA Contact:	Cluster QE <mspqa-list>
Severity:	low	Docs Contact:
Priority:	low
Version:	5.3	CC:	adas, cluster-maint, edamato, swhiteho, teigland
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-06-26 15:19:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	447748
Bug Blocks:

Description Robert Peterson 2008-06-17 16:24:46 UTC

Description of problem:
We're splitting out the locking protocols between gfs and gfs2.
Even though it's in the gfs2 kernel source tree, lock_dlm module will
now only look for gfs 1's gfs-kernel "gfs_register_lockproto".
Therefore, the cman init script cannot automatically load it as before.

The loading of lock_dlm either needs to be done from the gfs init
script or not at all (and let the module dependencies take care of it).

Version-Release number of selected component (if applicable):
RHEL5.3 plus the fix for bug #447748 

How reproducible:
Always

Steps to Reproduce:
1. service cman start

Actual results:
[root@exxon-01 ../fs/gfs2]# service cman start
Starting cluster: 
   Loading modules... failed
FATAL: Error inserting lock_dlm
(/lib/modules/2.6.18-prep/extra/locking/dlm/lock_dlm.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
                                                           [FAILED]
On the console or in dmesg:
lock_dlm: Unknown symbol gfs_register_lockproto
lock_dlm: Unknown symbol gfs_unregister_lockproto

Expected results:
[root@exxon-01 ../fs/gfs2]# service cman start
Starting cluster: 
   Loading modules... done
   Mounting configfs... done
   Starting ccsd... done
   Starting cman... done
   Starting daemons... done
   Starting fencing... done
                                                           [  OK  ]


Additional info:

Comment 1 David Teigland 2008-06-24 17:13:33 UTC

How about the cman init script modprobe's gfs, then modprobe's lock_dlm,
and ignores any failures?

Comment 2 Robert Peterson 2008-06-26 15:19:01 UTC

The decision was made to keep the lock_dlm in place for GFS2 and split
it off by cloning it for the GFS1 package.  Therefore, lock_dlm will
still be in place, at least for 5.3.  Therefore, we don't need to change
the init script.  Closing as NOTABUG.