I tried testing a work in progress 1.6.22.2 on rhel 7.5 beta by doing

git clone git://git.openafs.org/openafs.git
cd openafs
git checkout remotes/origin/openafs-stable-1_6_x
HEAD is now at d25c8e8... Make OpenAFS 1.6.22.2


But it seems to have the same problems with directories so I guess further
changes will need to be made to get it to work on rhel 7.5 kernel. Not a
kernel hacker so I'll wait to see what you guys come up with. :)

Thanks,

On Thu, Feb 1, 2018 at 11:11 AM, Stephan Wiesand <stephan.wies...@desy.de>
wrote:

> Comparing the 1.6.22.2 module builds from the SL packaging, where the kABI
> hashes of the used symbols are stored as a requirement, is seems none of
> those hashes changed between -693 and -830.
>
> There are two differences in the configure results:
>
> -ac_cv_linux_header_sched_signal_h=no
> +ac_cv_linux_header_sched_signal_h=yes
>
> -ac_cv_linux_struct_file_operations_has_iterate=no
> +ac_cv_linux_struct_file_operations_has_iterate=yes
>
> And there's quite a bit of churn in include/linux.fs.h (and some in key.h).
>
> > On 1. Feb 2018, at 16:58, 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-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!
> >
> >
> >
> >
>
> --
> 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
>

Reply via email to