Package Details: openafs-modules-dkms 1.8.2-2

Git Clone URL: https://aur.archlinux.org/openafs-modules-dkms.git (read-only)
Package Base: openafs-modules-dkms
Description: Kernel module for OpenAFS (dkms)
Upstream URL: http://www.openafs.org
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs<1.6.6-2, openafs-features-libafs, openafs-modules
Provides: openafs-modules=1.8.2
Submitter: Bevan
Maintainer: Bevan
Last Packager: Bevan
Votes: 16
Popularity: 0.014128
First Submitted: 2014-03-23 13:24
Last Updated: 2018-12-21 21:49

Latest Comments

1 2 3 4 5 6 Next › Last »

JMurph2015 commented on 2018-10-26 10:48

Seems to have been a transient thing with my installation. Not sure what went wrong that last time, but the main symptom was when rebuilding modules for the kernel, one of the threads would report as having become stuck for more than 120s or something along those lines.

For whatever reason, it's decided not to have problems this time around. The -j`nproc` thing is nice, but since ./configure is taking the vast majority of the time, it's really not a big deal.

Bevan commented on 2018-10-24 19:51

@JMurph2015: Thanks for your report and the debugging. I wasn't aware of any issue until now. The issues caused by obtaining MAKEFLAGS from makepkg.conf have been eliminated in June already by entirely dropping that logic. They aren't worth the amount of pain, I agree.

So the issue you are seeing must be something different and I have never experienced that before. The -jnproc clearly is a convenient thing but still may be a good idea. The quoted "yes" should not make any difference. So the remaining change is quoting the call to 'make'. Could you try only applying that change to see if it fixes the issue for you? I'll gladly include it here but I'd like to know if it is the culprit.

JMurph2015 commented on 2018-10-24 18:53

By the way, I think I have a fix. I took a look at the nvidia DKMS configuration and noticed a couple of things.

First, they had the AUTOINSTALL=yes quoted to AUTOINSTALL="yes", which may have been the issue.

Second, they had the call to make quoted as 'make' for some interesting reason explained in the file regarding make flags.

And third (really this is just a convenience thing), they had -j`nproc` after the quoted call to make to speed compilation up.

Overall, making those changes, that results in the below file. This works correctly when I call "pacman -S linux", so I'd assume it works on an upgrade as well (as opposed to a reinstall). Thanks!

PACKAGE_NAME="openafs"
PACKAGE_VERSION="1.8.2"

BUILT_MODULE_NAME[0]="openafs"
BUILT_MODULE_LOCATION[0]="src/libafs/MODLOAD-$kernelver-SP"
DEST_MODULE_LOCATION[0]="/kernel/fs"
AUTOINSTALL="yes"

MAKE[0]="(./configure --prefix=/usr \
              --sysconfdir=/etc \
              --sbindir=/usr/bin \
              --libexecdir=/usr/lib \
              --disable-fuse-client \
              --with-linux-kernel-packaging \
              --with-linux-kernel-headers=${kernel_source_dir} \
          && 'make' -j`nproc`)"
CLEAN="[ ! -f Makefile ] || 'make' clean"

JMurph2015 commented on 2018-10-24 18:17

This is still not building on the pacman hook (even with MAKEFLAGS="-j16" set in my /etc/makepkg.conf). Just last night my kernel upgraded and I was really messed up because it prevented the kernel from installing correctly and when I rebooted things got really bad. I ended up having to use an archiso to remove openafs entirely, reinstall my kernel, then reboot and fix things. Whatever those MAKEFLAGS, they aren't worth that amount of pain.

drslmr commented on 2018-06-21 13:52

Trying the command with "echo" also produced no output. Even after trying it with "remove" and later "install" again, there was not output. But the cause of problem seams to be identified by seally1186.

Bevan commented on 2018-06-21 13:39

seally1186: That sounds very plausible. I'll verify and work around this later today. Thanks a lot!

seally1186 commented on 2018-06-21 13:38

Hi,

I think the issue is in the "export $(grep -m1 '^MAKEFLAGS=' /etc/makepkg.conf)" line of dkms.conf. If MAKEFLAGS isn't set in /etc/makepkg.conf, this prints a bunch of text, causing check_buildexclusive in alpm-hook to fail.

Adding a definition for MAKEFLAGS caused the hook to start working for me.

Bevan commented on 2018-06-20 11:50

Ah, indeed the hook expects input on STDIN. I'll try this myself later and post the required command to test the hook.

Here is how the command should look like: echo usr/src/openafs-1.8.0/dkms.conf|sudo /bin/bash /usr/lib/dkms/alpm-hook install

Could you retest with this variant?

drslmr commented on 2018-06-20 11:34

I just upgraded and the issue still exists.

$ sudo /bin/bash /usr/lib/dkms/alpm-hook install seams to hang.

I tried to run the alpm-hook manually. And it looks like it is hanging because it awaits input from stdin at " while read -r path; do" Well, I have no clue if that was a sensible test.

RobvW commented on 2018-06-20 09:57

Bevan: I have to wake-up for missing the dot, thanks for spotting it. Now the dkms install -m openafs... does it.

Unfortunately this is the only dkms module package I install myself that I am aware of (when checking source tree location mentionned in /etc/dkms it points to /usr/src, which only contains openafs, as does /var/lib/dkms as well).