[OpenAFS] Start of afsd fails with "afsd: Error -1 in basic
Thu, 11 Feb 2016 22:20:04 -0500 (EST)
On Thu, 11 Feb 2016, Karl-Philipp Richter wrote:
> Am 10.02.2016 um 17:27 schrieb Benjamin Kaduk:
> > Those are from the in-tree kafs provider, which is completely unrelated to
> > openafs. I would expect that trying to run both that and openafs at the
> > same time would end poorly.
> Installing `openafs-modules-dkms` package on Ubuntu 15.10 which depends
> on `openafs-client` causes `openafs` module to be loaded instead of the
> listed, yet that requires me to repeat the installation for the system
> packages rather than fix the source installation. Imo it just fails to
> install the kernel modules. According to the very outdated QuickStart
> guide one ought to copy '.ko' and '.o' files to `/usr/vice/etc/modload`,
> but that doesn't help and I don't see the point.
Ah, I think I had misunderstood the initial report; my apologies for
reading too quickly and missing that.
> I attach the build log and will try to file a bug against every
> unhelpful error message I'll encounter the next days.
Thanks. I can't promise all of them will be fixed promptly, but it is
always good to know what can be improved.
> It's very hard to get OpenAFS running without up-to-date documentation
> and exclusively unhelpful feedback from commands.
Understood. Until the updated documentation is uploaded (and afterwards),
you may be able to get better turnaround time for installation (or other)
questions in #openafs on freenode.
A couple other points: there is an openafs-doc package that may be
slightly more up-to-date than the version currently on the website, but
most of the documentation changes are not pulled up to the 1.6.x branch,
so it would still be pretty bad.
If you want to try grafting current master into a debian package, for
better integration with the system tools and to use someone else's scheme
for getting the kernel modules into a useable location, I have a WIP from
the last time I tried this at
https://github.com/kaduk/openafs/tree/bleeding . But it is probably only
interesting if you already have experience with debian packaging, and of
course the stock upstream tree ought to be made usable without depending
on OS packaging.