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:
How about the cman init script modprobe's gfs, then modprobe's lock_dlm, and ignores any failures?
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.