Just for the sake of testing, I also installed 1.8.0pre4 RPMs on a RHEL 7.5
beta system and still had the same issue when using ls with directories
Also (maybe this was already mentioned), it seems to be only directories as
well. I can do an ls of a known file in my AFS home directory just fine:
[mvanderw@<host> ~]$ echo testing > /afs/crc.nd.edu/user/m/mvanderw/testing
[mvanderw@<host> ~]$ cat /afs/crc.nd.edu/user/m/mvanderw/testing
[mvanderw@<host> ~]$ ls -al /afs/crc.nd.edu/user/m/mvanderw/testing
-rw-r--r-- 1 mvanderw campus 8 Feb 2 11:20 /afs/
[mvanderw@<host> ~]$ ls -al /afs/crc.nd.edu/user/m/mvanderw
ls: reading directory /afs/crc.nd.edu/user/m/mvanderw: Not a directory
Any ideas? Or anything we can test/do that would help?
Matt Vander Werf
HPC System Administrator
University of Notre Dame
Center for Research Computing - Union Station
506 W. South Street
South Bend, IN 46601
Phone: (574) 631-0692
On Fri, Feb 2, 2018 at 4:05 AM, Stephan Wiesand <stephan.wies...@desy.de>
> > On 2. Feb 2018, at 09:55, Stephan Wiesand <stephan.wies...@desy.de>
> >> On 2. Feb 2018, at 02:14, Benjamin Kaduk <ka...@mit.edu> wrote:
> >> On Thu, Feb 01, 2018 at 05:11:24PM +0100, Stephan Wiesand wrote:
> >>> Comparing the 188.8.131.52 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
> >> That's very helpful to know.
> >> Does the new tree actually have a sched/signal.h header?
> > Yes it does. The only content is a guarded include of <linux/sched.h>
> >> Does the new struct file_operations have an 'iterate' member
> >> function?
> > Yes it does, wrapped in a RH_KABI_ITERATE macro.
> er, nonsense, that's RH_KABI_EXTEND, sorry
> >> (The idea being to tell whether they changed something in new and
> >> interesting ways or our configure test(s) are broken.)
> > It's the former :-(
> OpenAFS-info mailing list