Bug 811547

Summary: Request for sane allocation of gfs2 related modules to packages
Product: [Fedora] Fedora Reporter: Steve Whitehouse <swhiteho>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 17CC: adas, anprice, bmarzins, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mbroz, rbergero, rpeterso, teigland
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-3.3.2-8.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-24 04:29:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Steve Whitehouse 2012-04-11 11:44:53 UTC
Description of problem:

The kernel package contains the DLM module
The kernel-modules-extra package contains GFS2, OCFS2, SCTP modules

DLM depends on SCTP
GFS2 depends on DLM

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

Kernels with kernel-modules-extra sub-package

How reproducible:

Everytime

  
Actual results:

GFS2 appears not to be supported by the Fedora kernel unless the kernel-modules-extra package is installed. 

Expected results:

GFS2 should work "out of the box" or at least there should be some warning that the extra package is required.

The suggested solution on the fedora devel mailing list is to request that GFS2 and SCTP modules be moved back into the main kernel package. That is certainly the easiest solution as far as gfs2 is concerned.

Additional info:

See thread "kernel-modules-extra and GFS2" on <devel.org>

Comment 1 Josh Boyer 2012-04-11 13:26:48 UTC
(In reply to comment #0)
> Description of problem:
> 
> The kernel package contains the DLM module
> The kernel-modules-extra package contains GFS2, OCFS2, SCTP modules
> 
> DLM depends on SCTP

Actually, it doesn't:

[jwboyer@zod linux-2.6]$ modinfo dlm
filename:       /lib/modules/3.3.1-3.fc17.x86_64/kernel/fs/dlm/dlm.ko
license:        GPL
author:         Red Hat, Inc.
description:    Distributed Lock Manager
depends:        
intree:         Y
vermagic:       3.3.1-3.fc17.x86_64 SMP mod_unload 
[jwboyer@zod linux-2.6]$ 

At least not in the strict module dependency terms, which is why it isn't sucked into the kernel-module-extras package automatically.  It does select IP_SCTP at build time though.  It seems the DLM code is just using the generic socket calls with IPPROTO_SCTP.  Perhaps that should be a depends in the DLM Kconfig instead of a select.

Anyway, that's a different issue than what this bug report is covering.

> The suggested solution on the fedora devel mailing list is to request that GFS2
> and SCTP modules be moved back into the main kernel package. That is certainly
> the easiest solution as far as gfs2 is concerned.

Seems like an easy solution.

Comment 2 Josh Boyer 2012-04-11 17:13:35 UTC
(In reply to comment #1)
> > The suggested solution on the fedora devel mailing list is to request that GFS2
> > and SCTP modules be moved back into the main kernel package. That is certainly
> > the easiest solution as far as gfs2 is concerned.
> 
> Seems like an easy solution.

We'll hold off until we discuss this in the kernel team meeting Friday.

Comment 3 Steve Whitehouse 2012-04-17 10:18:41 UTC
Action items from Friday's meeting (from memory!):

 - DLM module to move to kernel-modules-extra
 - gfs2-utils to have a dep on kernel-modules-extra added to it
   ditto for other userland packages requiring kernel-modules-extra modules

Also we need to ask Dave Teigland whether DLM can be made independent of the SCTP module (we know that it is possible to insmod DLM without SCTP, but will it handle the case when a user requests to use SCTP in nicely in that case? If so then can the select SCTP in the DLM Kconfig be removed?)

Let me know if I missed anything here.

Comment 4 Josh Boyer 2012-04-17 14:30:08 UTC
(In reply to comment #3)
> Action items from Friday's meeting (from memory!):
> 
>  - DLM module to move to kernel-modules-extra
>  - gfs2-utils to have a dep on kernel-modules-extra added to it
>    ditto for other userland packages requiring kernel-modules-extra modules
> 
> Also we need to ask Dave Teigland whether DLM can be made independent of the
> SCTP module (we know that it is possible to insmod DLM without SCTP, but will
> it handle the case when a user requests to use SCTP in nicely in that case? If
> so then can the select SCTP in the DLM Kconfig be removed?)
> 
> Let me know if I missed anything here.

This sounds right to me.  Thanks for the summary/reminder Steve.  I'll get the kernel portions fixed up in F17/rawhide today.

Comment 5 David Teigland 2012-04-17 15:09:29 UTC
As of this recent commit: http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2f2d76cc3e938389feee671b46252dde6880b3b7

the dlm module depends on the "sctp_do_peeloff" symbol from the sctp module.  While it would be nice to make the dlm independent of the sctp module again, I don't see how that's possible.

Comment 6 Josh Boyer 2012-04-17 15:21:12 UTC
(In reply to comment #5)
> As of this recent commit:
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2f2d76cc3e938389feee671b46252dde6880b3b7
> 
> the dlm module depends on the "sctp_do_peeloff" symbol from the sctp module. 
> While it would be nice to make the dlm independent of the sctp module again, I
> don't see how that's possible.

OK.  So that actually picks up the correct dependency on sctp in the dlm.ko:

[jwboyer@vader kernel]$ modinfo dlm
filename:       /lib/modules/3.4.0-0.rc3.git0.1.fc18.x86_64/kernel/fs/dlm/dlm.ko
license:        GPL
author:         Red Hat, Inc.
description:    Distributed Lock Manager
depends:        sctp
intree:         Y
vermagic:       3.4.0-0.rc3.git0.1.fc18.x86_64 SMP mod_unload 
[jwboyer@vader kernel]$ 

That should cover it going forward.  The 3.3 and older kernel will basically just live as-is I guess.

Comment 7 Josh Boyer 2012-04-17 20:29:33 UTC
OK.  This is fixed in F17/rawhide.  It'll go out in the next update and bodhi will leave a comment here when it's in the repos.

Comment 8 Steve Whitehouse 2012-04-18 08:46:41 UTC
Thanks - sounds good.

Comment 9 Fedora Update System 2012-04-21 15:22:14 UTC
kernel-3.3.2-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kernel-3.3.2-8.fc17

Comment 10 Fedora Update System 2012-04-21 21:07:49 UTC
Package kernel-3.3.2-8.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.3.2-8.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6344/kernel-3.3.2-8.fc17
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-04-24 04:29:16 UTC
kernel-3.3.2-8.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.