Package Details: cvmfs 2.11.2-1

Git Clone URL: https://aur.archlinux.org/cvmfs.git (read-only, click to copy)
Package Base: cvmfs
Description: A client-server file system implemented in FUSE and developed to deliver software distributions onto virtual machines in a fast, scalable, and reliable way.
Upstream URL: http://cernvm.cern.ch/portal/filesystem
Licenses: BSD
Submitter: bins
Maintainer: fsiegert (vandelli)
Last Packager: vandelli
Votes: 11
Popularity: 0.000036
First Submitted: 2010-12-08 13:59 (UTC)
Last Updated: 2023-11-24 07:50 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

fsiegert commented on 2017-08-08 13:54 (UTC)

@Bigben37 Thanks for noticing this. I've fixed this typo without bumping the package version given that this doesn't change the installed files.

Bigben37 commented on 2017-08-08 13:21 (UTC)

Hi, thanks for providing this package :-) In cvmfs.install in line 10 a " is missing at the end. Because of this, the instructions in line 11 are not displayed properly. Cheers, Benjamin

fsiegert commented on 2017-07-09 20:39 (UTC)

@kgizdov: thanks for the hint, I have added the _netdev option to the mount command in the post-install message.

kgizdov commented on 2017-06-29 16:14 (UTC)

@kfinelli, that sounds more like Atlas scripts don't set the correct lib path to the ncurses version they used to compile ROOT against. If you set your environment from CVMFS and then do `ldd $(root-config --libdir)/*.so | grep -B 10 ncurses`, it will tell you whichever library (possibly libCling.so) does not find its dependency correctly.

kfinelli commented on 2017-06-29 12:04 (UTC)

This isn't directly related to the package, but might affect a lot of users- I noticed that in order to run ROOT as distributed on atlas cvmfs I needed to add the ncurses5-compat-libs from AUR. Another minor point is that the documentation link printed from cvmfs.install seems to be broken/out-of-date

kgizdov commented on 2017-06-26 21:21 (UTC)

Also, you should add `_netdev` as part of the mount options in `/etc/fstab`, otherwise you get a circular dependency on `network-online.target`. Check your `dmesg -l warn` output

kgizdov commented on 2017-06-25 13:39 (UTC)

@fsiegert, @vandelli, thanks for this - the systemd-mount works really nicely for me now. I think from now on that would be my default. I've tried AutoFS for other things before, but it never really worked correctly for me.

fsiegert commented on 2017-06-23 16:05 (UTC)

Thanks vandelli, that indeed seems to work great. I have pushed an updated PKGBUILD taking into account many of the suggestions from kgizdov (thanks!) and also the move to systemd.automount. When updating to that, please make sure you don't have any mounts from autofs left and also no directories created (manually) within /cvmfs. Let me know how this is working for you.

vandelli commented on 2017-06-23 06:00 (UTC)

Hi fsiegert, indeed I experienced similar problems with autofs. Eventually I kind of gave trying to understand the problem and instead started experimenting with systemd-automount. So far it works way better for me. This is what I added to /etc/fstab: atlas.cern.ch /cvmfs/atlas.cern.ch cvmfs noauto,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=5min,x-systemd.device-timeout=10 0 0 This is on my laptop where I do not CVMFS mounted unless I'm using it, hence the noauto and x-systemd.idle-timeout=5min Cheers Wainer

fsiegert commented on 2017-06-22 14:16 (UTC)

Hi kgizdov, thanks a lot, that looks very nice, in particular since one of the built-in libs doesn't compile with gcc7 anymore! I had tried something similar before, and have encountered the following problem, which also happens with your PKGBUILD: Mounting directly (as root using "mount") works fine, but when I set up the autofs to mount automatically on demand, the mount doesn't succeed. Strangely enough this didn't happen when using the built-in libs, only when compiling against the system ones! This seems to be some kind of race condition between the cvmfs process trying to mount the originally requested directory, e.g. /cvmfs/sft.cern.ch, and another cvmfs process spawned automatically, trying to mount /cvmfs/cvmfs-config.cern.ch. In other words, the first "sft" cvmfs process tried to access a file in that "cvmfs-config" directory, thus triggering the second process. If I simply "ls /cvmfs/cvmfs-config.cern.ch" first, and only then access e.g. /cvmfs/sft.cern.ch, then autofs works fine, indicating in my view that there seems to be some conflict between the two simultaneous processes. Can you (or anybody else) reproduce this? I'd like to have a cvmfs package with automount working, so if you have any idea for a solution or workaround that would be great. I have also been thinking about whether switching to systemd.automount (https://wiki.archlinux.org/index.php/Fstab#Automount_with_systemd) might be an option, anybody have any experience with that? PS: Good point on the autofs dependency!