Hello, > On 2. Mar 2018, at 09:47, Anders Nordin <anders.j.nor...@ltu.se> wrote: > > Hello, > > Is there any progress on this issue?
incidentally, Mark uploaded https://gerrit.openafs.org/12935 a couple of hours ago. It's probably not final since it seems to cause build failures on some older platforms. But it's certainly worth a try on EL7.5 beta systems. It would also be interesting to know on which other platforms it fails to build (or work). > Can we expect a stable release for RHEL 7.5? Once we have a change confirmed to fix the EL7.5 issue and not break other platforms, yes. Whether it will be available quite in time for 7.5 GA is hard to say. You can help... Best regards, Stephan > MVH > Anders > > -----Original Message----- > From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.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 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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
