Re: [OpenAFS] backup - order of entries in volume set
On 08/28/2015 03:02 AM, Benjamin Kaduk wrote: On Thu, 27 Aug 2015, Gunnar Krull wrote: Hi, when I have a backup Volume Set defined in this order, the volume user.backup is not included into the backup: Volume set userbackup: Entry 1: server .*, partition .*, volumes: user\..*\.backup Entry 2: server .*, partition .*, volumes: user\.backup But when I change the order of the two Volume Set entries, the volume user.backup is included: Volume set userbackup: Entry 1: server .*, partition .*, volumes: user\.backup Entry 2: server .*, partition .*, volumes: user\..*\.backup It's strange, but the order is irrelevant for another Volume Set. The difference to the example above is, that the resulting volume list to be backuped only consists of two volumes. Namely: svn.backup and svn.test.backup. I couldn't find an explanation for this behavior. Is there something wrong in my understanding of the volume set definitions? Most likely, there is a bug. Unfortunately, the backup code is some of the least-maintained and worst code in the tree that we still have some expectation of people actually using (which excludes kauth, among other things), so the reason is unlikely to be clear solely from code examination. To make matters worse, there are a few codepaths that could be taken; in what I think is the common case, the regex is actually evaluated on the vlserver, not on the machine running the backup utility. (Note that this means that different calls may get different results, if the vlservers are not homogeneous and have different regex libraries on them!) All servers are running on Debian Wheezy. So it should be quite homogeneous. I observed this behavior with OpenAFS 1.6.9 and now also with 1.6.14. As a first debugging step, I would suggest using wireshark or similar to capture traffic between the backup utility and the vlserver(s) to confirm whether the problem exists in the vlserver code or on the client side. The Wireshark records show that the backup client gets the complete volume list from the vlserver correctly, independent of the order in the volume set definition. I can see the two requests to the vlserver for both volume set entries and their corresponding responses including the volumes correctly. But the output and execution of the backup client depends on the order, like I described above. So, it seems to be the backup client that skips the volume and doesn't consider it for the actual backup. Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] backup - order of entries in volume set
On 08/28/2015 10:32 AM, Gunnar Krull wrote:
On 08/28/2015 03:02 AM, Benjamin Kaduk wrote:
On Thu, 27 Aug 2015, Gunnar Krull wrote:
Hi,
when I have a backup Volume Set defined in this order, the volume
user.backup is not included into the backup:
Volume set userbackup:
Entry 1: server .*, partition .*, volumes: user\..*\.backup
Entry 2: server .*, partition .*, volumes: user\.backup
But when I change the order of the two Volume Set entries, the volume
user.backup is included:
Volume set userbackup:
Entry 1: server .*, partition .*, volumes: user\.backup
Entry 2: server .*, partition .*, volumes: user\..*\.backup
It's strange, but the order is irrelevant for another Volume Set. The
difference to the example above is, that the resulting volume list to be
backuped only consists of two volumes. Namely: svn.backup and
svn.test.backup.
I couldn't find an explanation for this behavior.
Is there something wrong in my understanding of the volume set
definitions?
Most likely, there is a bug.
Unfortunately, the backup code is some of the least-maintained and worst
code in the tree that we still have some expectation of people actually
using (which excludes kauth, among other things), so the reason is
unlikely to be clear solely from code examination. To make matters
worse,
there are a few codepaths that could be taken; in what I think is the
common case, the regex is actually evaluated on the vlserver, not on the
machine running the backup utility. (Note that this means that different
calls may get different results, if the vlservers are not homogeneous and
have different regex libraries on them!)
All servers are running on Debian Wheezy. So it should be quite
homogeneous.
I observed this behavior with OpenAFS 1.6.9 and now also with 1.6.14.
As a first debugging step, I would suggest using wireshark or similar to
capture traffic between the backup utility and the vlserver(s) to confirm
whether the problem exists in the vlserver code or on the client side.
The Wireshark records show that the backup client gets the complete
volume list from the vlserver correctly, independent of the order in the
volume set definition.
I can see the two requests to the vlserver for both volume set entries
and their corresponding responses including the volumes correctly.
But the output and execution of the backup client depends on the order,
like I described above.
So, it seems to be the backup client that skips the volume and doesn't
consider it for the actual backup.
I think the reason for this is a strncmp in src/bucoord/commands.c
line 311:
for (tavols = ps-dupvdlist; add tavols;
tavols = tavols-next) {
if (strncmp(tavols-name, entries[e].name, l) == 0) {
if ((strcmp(entries[e].name[l], .backup) == 0)
|| (strcmp(entries[e].name[l], .readonly)
== 0)
|| (strcmp(entries[e].name[l], ) == 0))
add = 0;
}
}
To find and discard duplicate volumes, the list of volumes as a result
of the current volume set entry is compared to the list of volumes of
the previous volume set entry. A duplicate volume will not be added to
the list.
Unfortunately, the strncmp only compares the first l characters of the
string (l = length of the current volume name).
Also, it compares volume names with and without extensions (e.g .backup):
tavols-name : with extension (e.g. user.test1.backup)
entries[e].name : without extension (e.g. user.test1)
This leads to the problem I described above, for example:
Names of volumes: user.backup, user.test1.backup, user.test2.backup, ...
Volume set userbackup:
Entry 1: server .*, partition .*, volumes: user\..*\.backup
Entry 2: server .*, partition .*, volumes: user\.backup
Resulting list for Entry 1: user.test1.backup, user.test2.backup, ...
Resulting list for Entry 2: user
The string compare for Entry 2 would be:
strncmp(user.test1.backup, user, 4)
This is true and the volume user.backup will not be added to the list.
(I don't understand the following if statement with three strcmp ...)
I hope this is correct and the explanation understandable.
Regards,
Gunnar
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] backup - order of entries in volume set
Hi, when I have a backup Volume Set defined in this order, the volume user.backup is not included into the backup: Volume set userbackup: Entry 1: server .*, partition .*, volumes: user\..*\.backup Entry 2: server .*, partition .*, volumes: user\.backup But when I change the order of the two Volume Set entries, the volume user.backup is included: Volume set userbackup: Entry 1: server .*, partition .*, volumes: user\.backup Entry 2: server .*, partition .*, volumes: user\..*\.backup It's strange, but the order is irrelevant for another Volume Set. The difference to the example above is, that the resulting volume list to be backuped only consists of two volumes. Namely: svn.backup and svn.test.backup. I couldn't find an explanation for this behavior. Is there something wrong in my understanding of the volume set definitions? Thanks, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] backup: Volume name is illegal ; Failed to evaluate volume set
Hi! Yesterday I upgraded the OpenAFS packages on our servers running Debian Wheezy from 1.6.9-1~bpo70+1 to 1.6.13-1 (compiled and build from sid source). Since then the backup command stopped working with an error, e.g.: # /usr/sbin/backup dump -volumeset coursebackup -dump /aug Starting dump of volume set 'coursebackup' (dump level '/aug') backup: Volume name is illegal ; Failed to evaluate volume set The backup volume set looks like this: backup listv Volume set coursebackup: Entry 1: server .*, partition .*, volumes: course\..*\.backup Everything else seemed to be okay, no problems with fileservers and volume servers. Now, I've gone back to the old version, installing the 1.6.9 packages. With this version the backup is working again. Any idea what could cause the error in the latest version? Thanks, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] pts create cross realm users
On Thursday 29 July 2010 16:21:41 Jeffrey Altman wrote: On 7/29/2010 7:48 AM, Gunnar Krull wrote: Hi all, I have run into a problem creating cross realm users for our cell. It all goes fine until the username exceeds a certain length. For example: pts createuser -name asdfa...@student.uni-goettingen.de -cell informatik.uni- goettingen.de User asdfa...@student.uni-goettingen.de has id 1638879 pts createuser -name asdfas...@student.uni-goettingen.de -cell informatik.uni- goettingen.de pts: Badly formed name (group prefix doesn't match owner?) ; unable to create user asdfas...@student.uni-goettingen.de The documentation states that the username can consists of up to 63 characters. Thus I presume that the cell name is added to the username which indeed would exactly reach the length limit. Is that presumption correct? It is roughly correct. The cell name is not transmitted as part of the RPC to the pt server but when the foreign cell group entry is constructed the name ends up exceeding the limit. When and where does this happen? There is no workaround with the existing design of the pt server database. An alternative pt server database schema could be devised and implemented that would permit the full 63 characters to be used for foreign users. In the prdb.DB0 database file I can only find entries in form of usern...@foreigncell. That would not exceed the 63 characters limit with long names. The local cell name is not part of the database entries. I'm trying to understand how the this works ... Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: pts create cross realm users
On Fri, 30 Jul 2010, Andrew Deason wrote: On Fri, 30 Jul 2010 15:06:03 +0200 Gunnar Krull gkli...@cs.uni-goettingen.de wrote: In the prdb.DB0 database file I can only find entries in form of usern...@foreigncell. That would not exceed the 63 characters limit with long names. The local cell name is not part of the database entries. In case it wasn't clear from the other part of the thread, it is a bug that you were not able to create foreign entries that long. You are still prevented from making local entries that long, since doing so would break registering those entries in other cells. ok, that wasn't clear to me. If you want a fix right now and don't want to wait, there is a patch here to fix this (gerrit 2485): http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=56d93434ed57db3736cd992c151cfe47ba920c2d Note that that's only lightly tested on the 1.5 branch, and hasn't seen review from other developers yet, etc etc. But if you want to try it out (it should work on 1.4), there it is. Thank you for the hint. I will give it a try in the next week. Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] pts create cross realm users
Hi all, I have run into a problem creating cross realm users for our cell. It all goes fine until the username exceeds a certain length. For example: pts createuser -name asdfa...@student.uni-goettingen.de -cell informatik.uni- goettingen.de User asdfa...@student.uni-goettingen.de has id 1638879 pts createuser -name asdfas...@student.uni-goettingen.de -cell informatik.uni- goettingen.de pts: Badly formed name (group prefix doesn't match owner?) ; unable to create user asdfas...@student.uni-goettingen.de The documentation states that the username can consists of up to 63 characters. Thus I presume that the cell name is added to the username which indeed would exactly reach the length limit. Is that presumption correct? Is there any way to add users with longer usernames to our cell? Unfortunately, the Kerberos principals are mostly build like firstname.lastname and also our cell name is quite long. Thanks and regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Trouble with libnss-afs
On Wednesday 08 July 2009 00:19:31 Adam Megacz wrote: Russ Allbery r...@stanford.edu writes: One possibility: I could require =1.4.10 in order to build, but allow installation on earlier versions of OpenAFS. Will this work? Yup. Okay, libnss-afs 1.09 has been released. Debs are in the usual place. http://git.hcoop.net/?p=megacz/libnss-afs.git;h=tags/1.09 Please let me know if this works on amd64 (can't test it myself). Adam, thanks for the fix. Yes, I can confirm that it is working on a Lenny amd64 with libopenafs- dev_1.4.10 from backports installed. On an Ubuntu Jaunty amd64 it works with the dev package 1.4.11 from Karmic. Gunnar. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Trouble with libnss-afs
On Monday 06 July 2009 19:28:55 Adam Megacz wrote: mozafar roshany m.rosh...@gmail.com writes: I working on OpenAFS through this document on Debian Lenny: ... I should mention that I've installed the libnss-afs_1.08_i386.deb package or its 1.07 version. Hi, Mozafar. Could you please try upgrading to libnss-afs 1.08? I recently fixed a linking problem that only causes trouble for users of newer libc's: http://git.hcoop.net/?p=megacz/libnss-afs.git;a=commit;h=491cdaa05effc3 /afs/hcoop.net/user/m/me/megacz/public/libnss-afs/libnss-afs_1.08_i386.deb Note that the debs with 1.08 in their name were rebuilt recently; git is the authoritative source of version numbers. Hi Adam, the latest version 1.08 of libnss-afs cannot be build on a amd64 Ubuntu Jaunty. I'm getting this error message: gcc -shared -fPIC -o libnss_afs.so.2 nss_afs.o \ -Wl,-soname,libnss_afs.so.2 -L/usr/lib/afs -L/usr/lib -lafsauthent -lafsrpc -lpthread -lsys -lnsl -lresolv -g /usr/bin/ld: /usr/lib/libafsauthent.a(ubikclient.o): relocation R_X86_64_32 against `ubik_client_mutex' can not be used when making a shared object; recompile with -fPIC /usr/lib/libafsauthent.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libnss_afs.so.2] Error 1 But when I use the old LDFLAGS definition from version 1.07 the compilation is successful. Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Trouble with libnss-afs
On Wednesday 08 July 2009 00:19:31 Adam Megacz wrote: Russ Allbery r...@stanford.edu writes: One possibility: I could require =1.4.10 in order to build, but allow installation on earlier versions of OpenAFS. Will this work? Yup. Okay, libnss-afs 1.09 has been released. Debs are in the usual place. http://git.hcoop.net/?p=megacz/libnss-afs.git;h=tags/1.09 Please let me know if this works on amd64 (can't test it myself). Adam, thanks for the fix. Yes, I can confirm that it is working on a Lenny amd64 with libopenafs- dev_1.4.10 from backports installed. On an Ubuntu Jaunty amd64 it works with the dev package 1.4.11 from Karmic. Gunnar. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Wednesday 06 December 2006 23:49, Jeffrey Hutzelman wrote: On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull [EMAIL PROTECTED] wrote: # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) There are two tables - one for native programs, and one for 32-bit programs. We found both. * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab That's normal; unless you patch your kernel to export this symbol or provide its address on the command line, the NFS translator will not be supported. Unlike the system call table, this is not something we can scan for. # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 That's the whole trace? That's pretty useless. But no, this is not the cause of your problem. Yes, that's the whole trace. Nothing more the kernel want's to say. The same result now with version 1.5.12. I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... The 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? IIRC, the issue in question only affected amd64 systems. -- Jeff Thanks a lot for your answers! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Thursday 07 December 2006 10:03, Marcus Watts wrote: Gunnar Krull [EMAIL PROTECTED] and others wrote: ... I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) 19270410 is RXKADSEALEDINCON, which effectively means that either you or the fileserver is not encrypting data correctly. Usually it means that one of you is using the wrong key, but in this case, there is a known problem on some 64-bit platforms, which should be fixed in the next release. The encryption and keys on the server side are correct. I've checked this to be sure that the problem is the client. Sparc64 in combination with Linux/Debian is the only effected architecture here. So, I'm waiting impatiently for the fixed release ... This sounds like it might be the same problem that Steve Roseman [EMAIL PROTECTED] ran into on powerpc. In his case, his cache manager was using wrong-endian encryption right at the point of setting up an encrypted rx connection with a fileserver, so wasn't in fact capable of doing authenticated file access. The definitive proof would be to use tcpdump knowledge of the keys used to prove this is what happening, but you probably won't need to do that. I would be *very* interested in knowing two things: /1/ do pts and other userland commands work while using authenticated access with a token immediately before you access afs filespace and lose that token? ( since your error report contains your vice id, this seems likely to be true. ) Yes, that works. I can e.g. create and remove user groups with pts. Creating/removing volumes per vos command also works. Interestingly: after my token got discarded I can still execute commands that need authentication (pts, vos, ...) !? /2/ does this build fix produces a working cache manager for you? The simple kludge is to just append the line #define WORDS_BIGENDIAN 1 at the end of src/config/afsconfig.h after configuring afs, then at the top do ( cd src/libafs; make clean ) -- if you have old kernel objects in your build tree make only_libafs -- build just the cache manager You can then copy the cache manager pieces to your already existing system. Of course you can also build the whole thing. Just remember that if you type configure or config.status you'll have to patch afsconfig.h again. If these are both true, then that's good, that means I may actually have an interesting patch that will help you as well as others shortly. Also, you'll have a working cache manager, and won't need to be quite so impatient. :-) Yes, that's it! Now I can open files and directories in authentication only area of our afs filespace and the token resides in my system. I will test it more in the next days but it should be ok now. Thanks for the hint! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Kernel module on sparc64
Hi all, I have a problem with the OpenAFS kernel modules build on a dual-sparc64 with Debian Etch running, again. The modules for the different afs versions are compiled on a 2.6.18 Debian kernel (linux-image-2.6.18-2-sparc64-smp) and configured with: ./configure --with-afs-sysname=sparc64_linux26 I can compile the modules successfully, after dealing with the afs license problem I had before. The afs filespace also is accessible. This is the kernel output when I insert/remove the module: * With OpenAFS 1.4.2 # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 I think that's the reason why my token gets discarded when trying to access a protected folder of our afs filespace: afs: Tokens for user of AFS id 1032 for cell ** are discarded (rxkad error=19270410) There is a module parameter to set the authtab_addr but I don't know what to enter here. Can I set it manually or should it be done? The 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Compiling afs module on sparc64
On Wednesday 08 November 2006 14:28, Carsten Schulz-Key wrote: Gunnar Krull wrote: Why does the compile run on a sparc64 stop here? The error comes from the first case export_gpl and ends in a fatal message. What/where may be the reason of the differtent behavior between x86 and sparc64? According to the message in the following thread it is OK to ignore the error. http://www.openafs.org/pipermail/openafs-info/2006-July/022971.html If the module is loaded into the kernel at run-time, the kernel will complain about the license issues, but it will nevertheless load it. Maybe. But I cannot compile the OpenAFS module without modifying the source to ignore the error (like the configure script does). The easiest way I found to compile the module is to make OpenAFS temporary GPL compliant. I replaced all MODULE_LICENSE(http://www.openafs.org/dl/license10.html;); by MODULE_LICENSE(GPL); Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Compiling afs module on sparc64
On Tuesday 07 November 2006 22:57, Russ Allbery wrote:
Yup, that's because it's not GPL (it's released under the IBM Public
License).
However, normally it will build anyway. It sounds like there's some sort
of additional restriction on sparc64 that's not present on x86 or amd64
(at least) in the kernel.
With x86 I don't have any problems to compile it. I've tested it with the same
kernel source and the same afs source.
This is the function that creates the error message. From Debian kernel-source
linux-source-2.6.18_2.6.18-4_all.deb, file scripts/mod/modpost.c
static void check_for_gpl_usage(enum export exp, const char *m, const char *s)
{
const char *e = is_vmlinux(m) ?:.ko;
switch (exp) {
case export_gpl:
fatal(modpost: GPL-incompatible module %s%s
uses GPL-only symbol '%s'\n, m, e, s);
break;
case export_unused_gpl:
fatal(modpost: GPL-incompatible module %s%s
uses GPL-only symbol marked UNUSED '%s'\n, m, e, s);
break;
case export_gpl_future:
warn(modpost: GPL-incompatible module %s%s
uses future GPL-only symbol '%s'\n, m, e, s);
break;
case export_plain:
case export_unused:
case export_unknown:
/* ignore */
break;
}
}
Why does the compile run on a sparc64 stop here? The error comes from the
first case export_gpl and ends in a fatal message.
What/where may be the reason of the differtent behavior between x86 and
sparc64?
I also found this in the OpenAFS 1.5.10 config.log:
configure:12338: checking for exported sys_open
configure:12369: make -C $LINUX_KERNEL_PATH M=`pwd`/conftest.dir modules
/dev/null
FATAL: modpost: GPL-incompatible module conftest.ko uses GPL-only
symbol 'sys_open'
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
The configure script ignored this error and finished correctly.
Gunnar.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Compiling afs module on sparc64
Hi, I'm trying to compile the openafs module without success on a dual sparc64 Sun server running Debian Etch. With version 1.4.2 and 1.5.10 a make shows me this error message: echo 'char* AFSVersion = openafs 1.5.8; ' /tmp/openafs/openafs-1.5.10/openafs-1.5.10/src/libafs/MODLOAD-2.6.18-1-sparc64-smp-MP/AFS_component_version_number.c CC [M] /tmp/openafs/openafs-1.5.10/openafs-1.5.10/src/libafs/MODLOAD-2.6.18-1-sparc64-smp-MP/AFS_component_version_number.o LD [M] /tmp/openafs/openafs-1.5.10/openafs-1.5.10/src/libafs/MODLOAD-2.6.18-1-sparc64-smp-MP/libafs.o LD [M] /tmp/openafs/openafs-1.5.10/openafs-1.5.10/src/libafs/MODLOAD-2.6.18-1-sparc64-smp-MP/afspag.o Building modules, stage 2. MODPOST FATAL: modpost: GPL-incompatible module libafs.ko uses GPL-only symbol 'sys_call_table' The same result with smp kernel 2.6.17 and 2.6.18. Is there a way to compile the afs module on this system? Thanks for any suggestions! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Typo in dl of OpenAFS 1.2.13 for Debian
Hi, in the download of OpenAFS 1.2.13 for Debian http://www.openafs.org/dl/openafs/1.2.13/debian-3.0/ the file Packagez.gz should be called Packages.gz ... Also the file Installation Instructions in the same directory is not readable. Thanks for correcting this. Gunnar ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Typo in dl of OpenAFS 1.2.13 for Debian
Hi, in the download of OpenAFS 1.2.13 for Debian http://www.openafs.org/dl/openafs/1.2.13/debian-3.0/ the file Packagez.gz should be called Packages.gz ... Also the file Installation Instructions in the same directory is not readable. Thanks for correcting this. Gunnar ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
