[OpenAFS] Question for packagers
Hello! I'm a Sysadmin at a college that uses OpenAFS. I maintain our Redhat Satellite server, which can be set up to mirror external yum repositories. Generally that's what I do with other 3rd party packages such as Adobe or Puppetlabs. Those providers provide a yum repo path along the lines of: /distro/os-major-release/arch/latest -or- /distro/os-major-release/arch/product-major-release/latest ...which I can define once and use forever for the latest release of a product or a product major release version. This is very useful to me as it takes the pressure of watching for new minor releases to be released, then redefining my repository sync configuration each time the path changes to a new minor release. Is this something that the OpenAFS folks might consider adopting? Thanks, - Kodiak Firesmith
[OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
Folks, re-sending this because the first try never hit the list - perhaps mail with attachments are silently dropped or held for manual moderation? I'd originally attached an image of the stack trace. I'll host it and reply to this with a URL link in case that would also result in a drop or moderation. Anyhow: In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS fail to boot after the upgrade, with Openafs 1.6.22.1 installed. We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS uses might have changed with the latest kernel provided in RHEL 7. I've attached a picture of the trace. Anyone else kicking the tires on the new RHEL yet? Thanks!
[OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com> wrote: > Folks, re-sending this because the first try never hit the list - perhaps > mail with attachments are silently dropped or held for manual moderation? > I'd originally attached an image of the stack trace. I'll host it and > reply to this with a URL link in case that would also result in a drop or > moderation. > > > > Anyhow: > > In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS > fail to boot after the upgrade, with Openafs 1.6.22.1 installed. > > We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS > uses might have changed with the latest kernel provided in RHEL 7. > > I've attached a picture of the trace. > > Anyone else kicking the tires on the new RHEL yet? > > Thanks! > >
Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
Not much else to report today other than expanding my test base out to a few more RHEL 7.5b hosts, and re-rolled the 1.6.22.1-1 SRPM again, and am still seeing the same results universally. Every host fails to boot due to a kernel panic when it tries to load the openafs DKMS kernel module. My next move on Monday will be to try an actual kernel-specific kmod instead of DKMS. If that works I'll be kind of sad since we've had great luck with DKMS until now. - Kodiak On Thu, Feb 1, 2018 at 3:26 PM, Kodiak Firesmith <kfiresm...@gmail.com> wrote: > I just rebuilt off-the-shelf RPMs based off of http://www.openafs.org/dl/ > openafs/1.6.22.1/openafs-1.6.22.1-1.src.rpm thinking maybe we had some > historical patch in our build area that might be causing the problem, but > alas, even the off-the-shelf RPMs cause a full wedge and reboot when > openafs-client.service starts up. > > - Kodiak > > On Thu, Feb 1, 2018 at 1:23 PM, Kodiak Firesmith <kfiresm...@gmail.com> > wrote: > >> Hello Rich! >> It's a Dell Optiplex 7020 with an Intel i7-4790. >> >> Thanks! >> - Kodiak >> >> On Thu, Feb 1, 2018 at 1:20 PM, Rich Sudlow <r...@nd.edu> wrote: >> >>> On 01/31/2018 09:43 AM, Kodiak Firesmith wrote: >>> >>>> https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 >>>> >>> >>> Greetings >>> >>> What processor..etc is this machine? >>> >>> Rich >>> >>> >>> >>>> >>>> On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com >>>> <mailto:kfiresm...@gmail.com>> wrote: >>>> >>>> Folks, re-sending this because the first try never hit the list - >>>> perhaps >>>> mail with attachments are silently dropped or held for manual >>>> moderation? I'd originally attached an image of the stack trace. I'll >>>> host it and reply >>>> to this with a URL link in case that would also result in a drop >>>> or moderation. >>>> >>>> >>>> >>>> Anyhow: >>>> >>>> In testing the new RHEL 7.5 beta, we've discovered that hosts using >>>> AFS fail >>>> to boot after the upgrade, with Openafs 1.6.22.1 installed. >>>> >>>> We are wondering if some of the non-guaranteed kernel ABIs that >>>> OpenAFS uses >>>> might have changed with the latest kernel provided in RHEL 7. >>>> >>>> I've attached a picture of the trace. >>>> >>>> Anyone else kicking the tires on the new RHEL yet? >>>> >>>> Thanks! >>>> >>>> >>>> >>> >>> -- >>> Rich Sudlow >>> University of Notre Dame >>> Center for Research Computing - Union Station >>> 506 W. South St >>> South Bend, In 46601 >>> >>> (574) 631-7258 (office) >>> (574) 807-1046 (cell) >>> >> >> >
Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
Thanks Stephan, I'm relatively new to handling OpenAFS. Are these problems part of a normal "kernel release; openafs update" cycle and perhaps I'm getting snagged just by being too early of an adopter? I wanted to raise the alarm on this and see if anything else was needed from me as the reporter of the issue, but perhaps that's an overreaction to what is just part of a normal process I just haven't been tuned into in prior RHEL release cycles? Should I try to get an account set up at http://rt.central.org and file a bug? Thanks! - Kodiak On Fri, Feb 2, 2018 at 4:36 PM, Stephan Wiesand <stephan.wies...@desy.de> wrote: > While additional data points are obviously most welcome, there is no > expectation that this issue is fixed with 1.6.22.x or 1.8.x right now. Some > serious work will be required to adapt OpenAFS to the changes in this > kernel (series), though there's some hope that it won't be quite as hard to > fix as the 7.4 getcwd issue. > > - Stephan > > > On 02.Feb 2018, at 22:20, Kodiak Firesmith <kfiresm...@gmail.com> wrote: > > > > Not much else to report today other than expanding my test base out to a > few more RHEL 7.5b hosts, and re-rolled the 1.6.22.1-1 SRPM again, and am > still seeing the same results universally. Every host fails to boot due to > a kernel panic when it tries to load the openafs DKMS kernel module. > > > > My next move on Monday will be to try an actual kernel-specific kmod > instead of DKMS. If that works I'll be kind of sad since we've had great > luck with DKMS until now. > > > > - Kodiak > > > > On Thu, Feb 1, 2018 at 3:26 PM, Kodiak Firesmith <kfiresm...@gmail.com> > wrote: > > I just rebuilt off-the-shelf RPMs based off of > http://www.openafs.org/dl/openafs/1.6.22.1/openafs-1.6.22.1-1.src.rpm > thinking maybe we had some historical patch in our build area that might be > causing the problem, but alas, even the off-the-shelf RPMs cause a full > wedge and reboot when openafs-client.service starts up. > > > > - Kodiak > > > > On Thu, Feb 1, 2018 at 1:23 PM, Kodiak Firesmith <kfiresm...@gmail.com> > wrote: > > Hello Rich! > > It's a Dell Optiplex 7020 with an Intel i7-4790. > > > > Thanks! > > - Kodiak > > > > On Thu, Feb 1, 2018 at 1:20 PM, Rich Sudlow <r...@nd.edu> wrote: > > On 01/31/2018 09:43 AM, Kodiak Firesmith wrote: > > https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 > > > > Greetings > > > > What processor..etc is this machine? > > > > Rich > > > > > > > > > > On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com > <mailto:kfiresm...@gmail.com>> wrote: > > > > Folks, re-sending this because the first try never hit the list - > perhaps > > mail with attachments are silently dropped or held for manual > moderation? I'd originally attached an image of the stack trace. I'll > host it and reply > > to this with a URL link in case that would also result in a drop or > moderation. > > > > > > > > Anyhow: > > > > In testing the new RHEL 7.5 beta, we've discovered that hosts using > AFS fail > > to boot after the upgrade, with Openafs 1.6.22.1 installed. > > > > We are wondering if some of the non-guaranteed kernel ABIs that > OpenAFS uses > > might have changed with the latest kernel provided in RHEL 7. > > > > I've attached a picture of the trace. > > > > Anyone else kicking the tires on the new RHEL yet? > > > > Thanks! > >
Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
I just rebuilt off-the-shelf RPMs based off of http://www.openafs.org/dl/openafs/1.6.22.1/openafs-1.6.22.1-1.src.rpm thinking maybe we had some historical patch in our build area that might be causing the problem, but alas, even the off-the-shelf RPMs cause a full wedge and reboot when openafs-client.service starts up. - Kodiak On Thu, Feb 1, 2018 at 1:23 PM, Kodiak Firesmith <kfiresm...@gmail.com> wrote: > Hello Rich! > It's a Dell Optiplex 7020 with an Intel i7-4790. > > Thanks! > - Kodiak > > On Thu, Feb 1, 2018 at 1:20 PM, Rich Sudlow <r...@nd.edu> wrote: > >> On 01/31/2018 09:43 AM, Kodiak Firesmith wrote: >> >>> https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 >>> >> >> Greetings >> >> What processor..etc is this machine? >> >> Rich >> >> >> >>> >>> On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com >>> <mailto:kfiresm...@gmail.com>> wrote: >>> >>> Folks, re-sending this because the first try never hit the list - >>> perhaps >>> mail with attachments are silently dropped or held for manual >>> moderation? I'd originally attached an image of the stack trace. I'll >>> host it and reply >>> to this with a URL link in case that would also result in a drop or >>> moderation. >>> >>> >>> >>> Anyhow: >>> >>> In testing the new RHEL 7.5 beta, we've discovered that hosts using >>> AFS fail >>> to boot after the upgrade, with Openafs 1.6.22.1 installed. >>> >>> We are wondering if some of the non-guaranteed kernel ABIs that >>> OpenAFS uses >>> might have changed with the latest kernel provided in RHEL 7. >>> >>> I've attached a picture of the trace. >>> >>> Anyone else kicking the tires on the new RHEL yet? >>> >>> Thanks! >>> >>> >>> >> >> -- >> Rich Sudlow >> University of Notre Dame >> Center for Research Computing - Union Station >> 506 W. South St >> South Bend, In 46601 >> >> (574) 631-7258 (office) >> (574) 807-1046 (cell) >> > >
Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
Thanks for the replies! We're using DKMS and expected the dynamic re-roll of the kmods to work like any other kernel upgrade but that doesn't seem to be the case. I need to dig deeper, especially now that there is evidence that it's just our site. Thanks a bunch everyone. - Kodiak On Thu, Feb 1, 2018 at 11:13 AM, Matt Vander Werf <mvand...@nd.edu> wrote: > I'm also seeing the same issue as Gary on some RHEL 7.5 beta boxes running > OpenAFS 1.6.22.1. Can't run ls under any /afs/.../.../etc directory, > including in my AFS home directory when logged in as myself. > > [mvanderw@ ~]$ ls > ls: reading directory .: Not a directory > [mvanderw@ ~]$ ls ~ > ls: reading directory /afs/crc.nd.edu/user/m/mvanderw: Not a directory > > [mvanderw@ ~]$ ls /afs/ > ls: reading directory /afs/: Not a directory > [mvanderw@ ~]$ ls /afs/crc.nd.edu > ls: reading directory /afs/crc.nd.edu: Not a directory > > But no kernel panics here either. > > @Kodiak: Is it possible you were running a kmod-openafs from an older > kernel? I compiled a new kmod-openafs RPM on a RHEL 7.5 beta system and it > works well. > > I compiled all the OpenAFS packages from the source RPM on the RHEL 7.5 > beta system itself and didn't run into any issues with the compile. > > Besides this, AFS seems to be running correctly with nothing in the logs > indicating any problems (like Gary mentioned). > > Any idea what might be causing this? Some semantic changes like with the > getcwd issue in RHEL 7.4? > > Thanks. > > -- > Matt Vander Werf > HPC System Administrator > University of Notre Dame > Center for Research Computing - Union Station > 506 W. South Street > <https://maps.google.com/?q=506+W.+South+Street+South+Bend,+IN+46601=gmail=g> > South Bend, IN 46601 > <https://maps.google.com/?q=506+W.+South+Street+South+Bend,+IN+46601=gmail=g> > Phone: (574) 631-0692 > > On Thu, Feb 1, 2018 at 10:58 AM, Gary Gatling <gsgat...@ncsu.edu> wrote: > >> Ok. This gets weirder. Any directory under /afs says Not a directory. But >> I can read files like >> >> /afs/eos.ncsu.edu/software/inventory/software_inventory >> >> just fine. >> >> On Thu, Feb 1, 2018 at 10:55 AM, Gary Gatling <gsgat...@ncsu.edu> wrote: >> >>> I don't get a kernel panic but instead I get: >>> >>> [gsgatlin@localhost ~]$ ls /afs/ >>> ls: reading directory /afs/: Not a directory >>> [gsgatlin@localhost ~]$ >>> >>> >>> which is pretty weird. I don't see anything in the syslog about problems >>> with openafs >>> >>> Feb 1 10:44:24 localhost systemd: Starting OpenAFS Client Service... >>> Feb 1 10:44:24 localhost kernel: libafs: loading out-of-tree module >>> taints kernel. >>> Feb 1 10:44:24 localhost kernel: libafs: module license ' >>> http://www.openafs.org/dl/license10.html' taints kernel. >>> Feb 1 10:44:24 localhost kernel: Disabling lock debugging due to kernel >>> taint >>> Feb 1 10:44:24 localhost kernel: libafs: module verification failed: >>> signature and/or required key missing - tainting kernel >>> Feb 1 10:44:24 localhost kernel: Key type afs_pag registered >>> Feb 1 10:44:24 localhost kernel: enabling dynamically allocated vcaches >>> Feb 1 10:44:24 localhost kernel: Starting AFS cache scan...Memory >>> cache: Allocating 1600 dcache entries...found 0 non-empty cache files (0%). >>> Feb 1 10:44:24 localhost afsd: afsd: All AFS daemons started. >>> Feb 1 10:44:24 localhost afsd: afsd: All AFS daemons started. >>> Feb 1 10:44:24 localhost systemd: Started OpenAFS Client Service. >>> >>> I am using openafs-1.6.22 >>> >>> >>> with >>> >>> correct-m4-conditionals-in-curses.m4.patch >>> linux-test-for-vfswrite-rather-than-vfsread.patch >>> linux-use-kernelread-kernelwrite-when-vfs-varian.patch >>> >>> from the arch linux distro in my rpm packages. >>> >>> Anyone know what >>> >>> ls: reading directory /afs/: Not a directory >>> >>> means and is there some way around it? >>> >>> Also, is 1.6.22.2 coming out soon? >>> >>> Thanks so much, >>> >>> On Wed, Jan 31, 2018 at 9:43 AM, Kodiak Firesmith <kfiresm...@gmail.com> >>> wrote: >>> >>>> https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 >>>> >>>> >>>> On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com >>>> > wrote: >>>> >>>>> Folks, re-se
Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
Hello again All, As part of continued testing, I've been able to confirm that the SystemD double-service startup thing only happens to my hosts when going from RHEL 7.4 to RHEL 7.5beta. On a test host installed directly as RHEL 7.5beta, I get a bit farther with 1.6.18.22, in that I get to the point where OpenAFS "kind of" works. What I'm observing is that the openafs client Kernel module (built by DKMS) loads fine, and just so long as you know where you need to go in /afs, you can get there, and you can read and write files and the OpenAFS 'fs' command works. But doing an 'ls' of /afs or any path underneath results in "ls: reading directory /afs/: Not a directory". I ran an strace of a good RHEL 7.4 host running ls on /afs, and a RHEL 7.5beta host running ls on /afs and have created pastebins of both, as well as an inline diff. All can be seen at the following locations: works https://paste.fedoraproject.org/paste/Hiojt2~Be3wgez47bKNucQ fails https://paste.fedoraproject.org/paste/13ZXBfJIOMsuEJFwFShBfg diff https://paste.fedoraproject.org/paste/FJKRwep1fWJogIDbLnkn8A Hopefully this might help the OpenAFS devs, or someone might know what might be borking on every RHEL 7.5 beta host. It does fit with what other 7.5 beta users have observed OpenAFS doing. Thanks! - Kodiak On Mon, Feb 5, 2018 at 12:31 PM, Stephan Wiesand <stephan.wies...@desy.de> wrote: > > > On 04.Feb 2018, at 02:11, Jeffrey Altman <jalt...@auristor.com> wrote: > > > > On 2/2/2018 6:04 PM, Kodiak Firesmith wrote: > >> I'm relatively new to handling OpenAFS. Are these problems part of a > >> normal "kernel release; openafs update" cycle and perhaps I'm getting > >> snagged just by being too early of an adopter? I wanted to raise the > >> alarm on this and see if anything else was needed from me as the > >> reporter of the issue, but perhaps that's an overreaction to what is > >> just part of a normal process I just haven't been tuned into in prior > >> RHEL release cycles? > > > > > > Kodiak, > > > > On RHEL, DKMS is safe to use for kernel modules that restrict themselves > > to using the restricted set of kernel interfaces (the RHEL KABI) that > > Red Hat has designated will be supported across the lifespan of the RHEL > > major version number. OpenAFS is not such a kernel module. As a result > > it is vulnerable to breakage each and every time a new kernel is shipped. > > Jeffrey, > > the usual way to use DKMS is to either have it build a module for a newly > installed kernel or install a prebuilt module for that kernel. It may be > possible to abuse it for providing a module built for another kernel, but > I think that won't happen accidentally. > > You may be confusing DKMS with RHEL's "KABI tracking kmods". Those should > be safe to use within a RHEL minor release (and the SL packaging has been > using them like this since EL6.4), but aren't across minor releases (and > that's why the SL packaging modifies the kmod handling to require a build > for the minor release in question. > > > There are two types of failures that can occur: > > > > 1. a change results in failure to build the OpenAFS kernel module > >for the new kernel > > > > 2. a change results in the OpenAFS kernel module building and > >successfully loading but failing to operate correctly > > The latter shouldn't happen within a minor release, but can across > minor releases. > > > It is the second of these possibilities that has taken place with the > > release of the 3.10.0-830.el7 kernel shipped as part of the RHEL 7.5 > beta. > > > > Are you an early adopter of RHEL 7.5 beta? Absolutely, its a beta > > release and as such you should expect that there will be bugs and that > > third party kernel modules that do not adhere to the KABI functionality > > might have compatibility issues. > > The -830 kernel can break 3rd-party modules using non-whitelisted ABIs, > whether or not they adhere to the "KABI functionality". > > > There was a compatibility issue with RHEL 7.4 kernel > > (3.10.0_693.1.1.el7) as well that was only fixed in the OpenAFS 1.6 > > release series this past week as part of 1.6.22.2: > > > > http://www.openafs.org/dl/openafs/1.6.22.2/RELNOTES-1.6.22.2 > > Yes, and this one was hard to fix. Thanks are due to Mark Vitale for > developing the fix and all those who reviewed and tested it. > > > Jeffrey Altman > > AuriStor, Inc. > > > > P.S. - Welcome to the community. > > Seconded. In particular, the problem report regarding the EL7.5beta > kernel was absolutely appropriate. > > -- > Stephan Wiesand > DESY - DV - > Platanenallee 6 > 15738 Zeuthen, Germany > > >
Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
I've also tested gsgatlin's 7.5beta RPMs and they work great. Any chance we'll see the rh75enotdir patch integrated into a release of 1.6.22.3 soon? I'm wondering if it'll be worth it to manually apply that patch to a rebuild of the official OpenAFS RPMs if this isn't on the block for being merged and released soon - but I don't want to blow the time applying that patch to a re-roll if a fixed official release is forthcoming. Thanks! - Kodiak On Fri, Mar 2, 2018 at 3:47 AM, Anders Nordin <anders.j.nor...@ltu.se> wrote: > Hello, > > Is there any progress on this issue? Can we expect a stable release for > RHEL 7.5? > > MVH > Anders > > -Original Message- > From: openafs-info-ad...@openafs.org [mailto:openafs-info-admin@ope > nafs.org] On Behalf Of Benjamin Kaduk > Sent: den 9 februari 2018 01:02 > To: Kodiak Firesmith <kfiresm...@gmail.com> > Cc: openafs-info <openafs-info@openafs.org> > Subject: Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up > > On Wed, Feb 07, 2018 at 11:46:28AM -0500, Kodiak Firesmith wrote: > > Hello again All, > > > > As part of continued testing, I've been able to confirm that the > > SystemD double-service startup thing only happens to my hosts when > > going from RHEL > > 7.4 to RHEL 7.5beta. On a test host installed directly as RHEL > > 7.5beta, I get a bit farther with 1.6.18.22, in that I get to the > > point where OpenAFS "kind of" works. > > Thanks for tracking this down. The rpm packaging maintainers may want to > try to track down why the double-start happens in the upgrade scenario, as > that's pretty nasty behavior. > > > What I'm observing is that the openafs client Kernel module (built by > > DKMS) loads fine, and just so long as you know where you need to go in > > /afs, you can get there, and you can read and write files and the > OpenAFS 'fs' > > command works. But doing an 'ls' of /afs or any path underneath > > results in > > "ls: reading directory /afs/: Not a directory". > > > > I ran an strace of a good RHEL 7.4 host running ls on /afs, and a RHEL > > 7.5beta host running ls on /afs and have created pastebins of both, as > > well as an inline diff. > > > > All can be seen at the following locations: > > > > works > > https://paste.fedoraproject.org/paste/Hiojt2~Be3wgez47bKNucQ > > > > fails > > https://paste.fedoraproject.org/paste/13ZXBfJIOMsuEJFwFShBfg > > > > > > diff > > https://paste.fedoraproject.org/paste/FJKRwep1fWJogIDbLnkn8A > > > > Hopefully this might help the OpenAFS devs, or someone might know what > > might be borking on every RHEL 7.5 beta host. It does fit with what > > other > > 7.5 beta users have observed OpenAFS doing. > > Yes, now it seems like all our reports are consistent, and we just have to > wait for a developer to get a better look at what Red Hat changed in the > kernel that we need to adapt to. > > -Ben > > > Thanks! > > - Kodiak > > > > On Mon, Feb 5, 2018 at 12:31 PM, Stephan Wiesand > > <stephan.wies...@desy.de> > > wrote: > > > > > > > > > On 04.Feb 2018, at 02:11, Jeffrey Altman <jalt...@auristor.com> > wrote: > > > > > > > > On 2/2/2018 6:04 PM, Kodiak Firesmith wrote: > > > >> I'm relatively new to handling OpenAFS. Are these problems part > > > >> of a normal "kernel release; openafs update" cycle and perhaps > > > >> I'm getting snagged just by being too early of an adopter? I > > > >> wanted to raise the alarm on this and see if anything else was > > > >> needed from me as the reporter of the issue, but perhaps that's > > > >> an overreaction to what is just part of a normal process I just > > > >> haven't been tuned into in prior RHEL release cycles? > > > > > > > > > > > > Kodiak, > > > > > > > > On RHEL, DKMS is safe to use for kernel modules that restrict > > > > themselves to using the restricted set of kernel interfaces (the > > > > RHEL KABI) that Red Hat has designated will be supported across > > > > the lifespan of the RHEL major version number. OpenAFS is not > > > > such a kernel module. As a result it is vulnerable to breakage each > and every time a new kernel is shipped. > > > > > > Jeffrey, > > > > > > the usual way to use DKMS is to either have it build a module for a > > > newly installed kernel or install a prebuilt module for that kernel. > > > It may
