Hi,
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
There was never a dep on the kernel package in gfs2-utils - it seemed a bit pointless, really :-) However I can see that we'll land up with a lot of confused users I think, when they get an error message implying that the Fedora kernel no longer supports GFS2.
Also, I wonder whether we could arrange for the loading of a kernel module that isn't installed, but that is in the kernel-modules-extra package to trigger some kind of notice to the user, that this is the case and they need to install the additional package?
Steve.
On Wed, Apr 11, 2012 at 10:52:19AM +0100, Steven Whitehouse wrote:
Hi,
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
Why not just open a BZ requesting that gfs2 be moved back into the main kernel RPM. IMHO having gfs2 in a separate kernel RPM just creates unnecessary complexity/pain for users.
Regards, Daniel
Hi,
On Wed, 2012-04-11 at 10:55 +0100, Daniel P. Berrange wrote:
On Wed, Apr 11, 2012 at 10:52:19AM +0100, Steven Whitehouse wrote:
Hi,
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
Why not just open a BZ requesting that gfs2 be moved back into the main kernel RPM. IMHO having gfs2 in a separate kernel RPM just creates unnecessary complexity/pain for users.
Regards, Daniel
Well that is one possibility - I'm trying to find the documentation that explains the criteria for modules being moved into the kernel-modules-extra package and I've not found any so far....
However, if that is the correct solution, then I'm quite happy with it, but it isn't immediately obvious as to whether it is or not,
Steve.
On Wed, Apr 11, 2012 at 6:03 AM, Steven Whitehouse swhiteho@redhat.com wrote:
Hi,
On Wed, 2012-04-11 at 10:55 +0100, Daniel P. Berrange wrote:
On Wed, Apr 11, 2012 at 10:52:19AM +0100, Steven Whitehouse wrote:
Hi,
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
Why not just open a BZ requesting that gfs2 be moved back into the main kernel RPM. IMHO having gfs2 in a separate kernel RPM just creates unnecessary complexity/pain for users.
Well that is one possibility - I'm trying to find the documentation that explains the criteria for modules being moved into the kernel-modules-extra package and I've not found any so far....
Essentially, it's:
"Things that are not widely used in a typical Fedora setup, or things that we might disable entirely but are moving to see if there are users that notice."
GFS2 falls into the first set, not the second.
However, if that is the correct solution, then I'm quite happy with it, but it isn't immediately obvious as to whether it is or not,
We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed.
josh
Hi,
On Wed, 2012-04-11 at 07:19 -0400, Josh Boyer wrote:
On Wed, Apr 11, 2012 at 6:03 AM, Steven Whitehouse swhiteho@redhat.com wrote:
Hi,
On Wed, 2012-04-11 at 10:55 +0100, Daniel P. Berrange wrote:
On Wed, Apr 11, 2012 at 10:52:19AM +0100, Steven Whitehouse wrote:
Hi,
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
Why not just open a BZ requesting that gfs2 be moved back into the main kernel RPM. IMHO having gfs2 in a separate kernel RPM just creates unnecessary complexity/pain for users.
Well that is one possibility - I'm trying to find the documentation that explains the criteria for modules being moved into the kernel-modules-extra package and I've not found any so far....
Essentially, it's:
"Things that are not widely used in a typical Fedora setup, or things that we might disable entirely but are moving to see if there are users that notice."
GFS2 falls into the first set, not the second.
Yes, but this makes no sense at all.... looking at the selection that has been made we have:
o DLM in the main kernel package o OCFS2 and GFS2 - the only two in-kernel users of DLM in kernel-modules-extra
I know that cLVM also uses DLM, but from userland and I wonder just how many people use cLVM who don't use of the cluster filesystems - probably a few, but most likely not a huge number. Perhaps more importantly, DLM depends on SCTP and SCTP is only in kernel-modules-extra, so I think this needs a rethink.
However, if that is the correct solution, then I'm quite happy with it, but it isn't immediately obvious as to whether it is or not,
We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed.
josh
I can certainly open a bug to request a more sane assignment of modules to packages, but just wanted to be sure of the criteria so that I am asking for the correct things,
Steve.
On Wed, Apr 11, 2012 at 7:36 AM, Steven Whitehouse swhiteho@redhat.com wrote:
On Wed, 2012-04-11 at 07:19 -0400, Josh Boyer wrote:
Well that is one possibility - I'm trying to find the documentation that explains the criteria for modules being moved into the kernel-modules-extra package and I've not found any so far....
Essentially, it's:
"Things that are not widely used in a typical Fedora setup, or things that we might disable entirely but are moving to see if there are users that notice."
GFS2 falls into the first set, not the second.
Yes, but this makes no sense at all.... looking at the selection that has been made we have:
o DLM in the main kernel package o OCFS2 and GFS2 - the only two in-kernel users of DLM in kernel-modules-extra
I know that cLVM also uses DLM, but from userland and I wonder just how many people use cLVM who don't use of the cluster filesystems - probably a few, but most likely not a huge number. Perhaps more importantly, DLM depends on SCTP and SCTP is only in kernel-modules-extra, so I think this needs a rethink.
Nobody said we got everything perfect. This kind of commentary and review is very useful.
However, if that is the correct solution, then I'm quite happy with it, but it isn't immediately obvious as to whether it is or not,
We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed.
I can certainly open a bug to request a more sane assignment of modules to packages, but just wanted to be sure of the criteria so that I am asking for the correct things,
Yeah, "criteria" is very loosely defined here. It mostly boiled down to educated guesses. Or in the case of SCTP, things we noticed weren't used heavily and were somewhat notorious for having security issues.
Thanks for opening the bug. We'll work it out there.
josh
On Wed, Apr 11, 2012 at 07:19:32 -0400, Josh Boyer jwboyer@gmail.com wrote:
We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed.
While I didn't request to move it back, I am using a driver for my game pad that is sitting in extras now. I doubt there are many other Fedora users who need that driver though.
On Wed, Apr 11, 2012 at 07:19:32AM -0400, Josh Boyer wrote:
I've had some reports recently that appeared to suggest that in F17, GFS2 was no longer being supported by the kernel. Having investigated this, it appears that the root cause is that the gfs2.ko module has been moved to a package called kernel-modules-extra (although the kernel RPM still contains the directory in which the gfs2 module sits, which is a bit odd - why package an empty directory?)
Now, I'm wondering whether I should add a dependency on kernel-modules-extra in the gfs2-utils package?
I'm leaning towards saying that would be the right thing to do.
"Things that are not widely used in a typical Fedora setup, or things that we might disable entirely but are moving to see if there are users that notice."
GFS2 falls into the first set, not the second.
For exactly this reason. Your comment about DLM is helpful, though I seem to recall there may have been another reason we couldn't move that to -extras at the time it was implemented. (Was that non-modular for a while maybe?).
We can move it back if needs be. Honestly, we might wind up just disabling the rest of the stuff contained in there and dropping the sub-package entirely. We're still kind of undecided on whether it's worth doing at all. Thus far there have been 3 requests to move a module back. The rest seem to be unnoticed.
I've added an item to discuss this on the agenda for this weeks Fedora kernel meeting[*] for anyone interested.
Dave
-
Bruno Wolff III -
Daniel P. Berrange -
Dave Jones -
Josh Boyer -
Steven Whitehouse