Bug 448684

Summary:	groupd fails sanity checks
Product:	[Fedora] Fedora	Reporter:	Fabio Massimo Di Nitto <fdinitto>
Component:	cman	Assignee:	David Teigland <teigland>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	10	CC:	agk, ccaulfie, fdinitto, mbroz, swhiteho
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-12-15 14:46:05 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:

Description Fabio Massimo Di Nitto 2008-05-28 08:11:04 UTC

Description of problem:

I have a local gfs2 (no_lock) partition mounted locally as /home.

I am only attempting to startup cman and the rest of the stack for testing
but groupd fails:

[root@cerberus ~]# groupd -D
1211961991 cman: our nodeid 66 name cerberus quorum 0
1211961991 found uncontrolled kernel object dm-1 in /sys/fs/gfs2
1211961991 local node must be reset to clear 1 uncontrolled instances of gfs
and/or dlm


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

2.03.02/stable2

How reproducible:

always

Steps to Reproduce:
1. create a local partition gfs2+no_lock and mount it via fstab / gfs2-utils script
2. start cman
3. start groupd
  
Actual results:

groupd fails to start (for other reasons cman seems to bail out too - to be
investigated)

Expected results:

groupd should ignore no_lock instances.

Comment 1 John Poelstra 2008-10-15 23:25:38 UTC

This bug has been triaged

Comment 2 Bug Zapper 2008-11-26 02:20:49 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Steve Whitehouse 2008-12-15 11:32:05 UTC

I think this has been fixed now. Perhaps we can close this one?