[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 17:40:02 -0500 Andrew Deason wrote: > > I edited: > > > > src/cf/osconf.m4 > > src/libuafs/MakefileProto.SOLARIS.in > > src/libafs/MakefileProto.SOLARIS.in > > Well, you need to re-configure each time (or modify the Makefiles > directly). And by that, I mean, run regen.sh and reconfigure. If I just edit src/cf/osconf.m4 and do that, it goes away for me. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 18:44:24 -0400 Derrick Brashear wrote: > or, for now, just replace that with > memset(dirHeader->hashTable, 0, NHASHENT*(unsigned short)); > > and move along? Yeah but, I'd like to get a better solution for when this happens again. Prohibiting loops like that would be a bizarre requirement :) -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Help: aklog cannot work properly
Hi, It seems aklog cannot work well in my server. [root@server ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@HERDINGCAT.INTERNAL Valid starting ExpiresService principal 06/01/11 00:55:12 06/02/11 00:55:10 krbtgt/HERDINGCAT.INTERNAL@HERDINGCAT.INTERNAL renew until 06/01/11 00:55:12 [root@server ~]# aklog -d -c herdingcat.internal Authenticating to cell herdingcat.internal (server server.herdingcat.internal). Trying to authenticate to user's realm HERDINGCAT.INTERNAL. Getting tickets: afs/herdingcat.internal@HERDINGCAT.INTERNAL Kerberos error code returned by get_cred : -1765328370 aklog: Couldn't get herdingcat.internal AFS tickets: aklog: unknown RPC error (-1765328370) while getting AFS tickets [root@server ~]# ls /afs ls: cannot access /afs/herdingcat.internal: No such device herdingcat.internal [root@server ~]# fs wscell This workstation belongs to cell 'openafs.org' [root@server ~]# And I noticed that the client belongs to openafs.org, how this could be? Could anyone show me how to fix that? Thanks very much. Eric ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4 and 1.6 compatibility
On Tue, May 31, 2011 at 10:14 PM, Dan Scott wrote: > Hello, > > I have a cell configured with 3 OpenAFS servers and 20 or so clients, > all running version 1.4.x of OpenAFS. I see that 1.6 is nearing > release and I have a few questions: > > 1. What are the new features of version 1.6? Demand Attach fileserver is the premiere 1.6 feature. Other things have also been added but most are much more minor > 2. Are 1.6 clients compatible with 1.4 servers? yes > 3. Are 1.4 clients compatible with 1.6 servers? yes > > What I'm really interested in knowing is can I upgrade my > servers/clients as/when convenient, or do I have to do them all in 1 > go? I'm hoping, since 1.4 and 1.6 both use protocol V3, they will be > compatible with each other? they will. you should upgrade your *database* servers all in one go, however. > > Sorry if this is all documented somewhere, but I couldn't find it on > the website - or the mailing list archives. > > Thanks, > > Dan Scott > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Help: Cannot execute pts createuser
Thanks Marcus, your way solved the problem. And shall I use -localauth for the following installation procedure? Andrew, yes, I followed a guide from the OpenAFS official website, http://docs.openafs.org/QuickStartUnix/index.html. And it says I shall use -noauth in installation procedure. Any ideas? Eric On Wed, Jun 1, 2011 at 12:35 AM, Andrew Deason wrote: > On Wed, 1 Jun 2011 00:22:49 +0800 > Lee Eric wrote: > >> [root@server ~]# pts createuser -name admin -noauth >> pts: Permission denied ; unable to create user admin >> [root@server ~]# pts createuser -name admin -id 1 -noauth >> pts: Entry for id already exists ; unable to create user admin with id 1 >> [root@server ~]# >> >> Could anyone show me some tips to fix that? > > Well, you're trying to add a user while unauthenticated (-noauth); > usually you need to be authenticated as an administrator in order to add > users. So, acquire admin credentials, or try running with -localauth > instead of -noauth. > > Are you following a guide or something? If so, what exactly did it say > to do? > > -- > Andrew Deason > adea...@sinenomine.net > > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS 1.4 and 1.6 compatibility
Hello, I have a cell configured with 3 OpenAFS servers and 20 or so clients, all running version 1.4.x of OpenAFS. I see that 1.6 is nearing release and I have a few questions: 1. What are the new features of version 1.6? 2. Are 1.6 clients compatible with 1.4 servers? 3. Are 1.4 clients compatible with 1.6 servers? What I'm really interested in knowing is can I upgrade my servers/clients as/when convenient, or do I have to do them all in 1 go? I'm hoping, since 1.4 and 1.6 both use protocol V3, they will be compatible with each other? Sorry if this is all documented somewhere, but I couldn't find it on the website - or the mailing list archives. Thanks, Dan Scott ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, May 31, 2011 at 2:13 PM, Andrew Deason wrote:
> On Tue, 31 May 2011 12:14:31 -0500
> Andrew Deason wrote:
>
>> Or I can just find it by commenting stuff out and seeing when the
>> _memset ref goes away. It appears to be this loop that's causing it, in
>> afs_RebuildDynroot lines 378/379:
>>
>> for (i = 0; i < NHASHENT; i++)
>> dirHeader->hashTable[i] = 0;
>>
>> which makes sense; that's pretty easily optimizable into a memset.
or, for now, just replace that with
memset(dirHeader->hashTable, 0, NHASHENT*(unsigned short));
and move along?
>> I'll get a simpler demonstration together to submit to Oracle.
>
> Also, Jeff, if you want a quick workaround, you can change -O to -O2 or
> just leave out the -O option. I think changing the value of KERN_OPTMZ
> in src/cf/osconf.m4 should be enough...
>
> And now I'm not completely sure if this is a bug or if we're just
> missing the magic incantation to make this not happen. A simple test
> case:
>
> void
> foo(short *arr)
> {
> int i;
> for (i = 0; i < 256; i++)
> arr[i] = 0;
> }
>
> If you compile with 'cc foo.c -c -o foo.o -O3', you get a reference to
> _memset. If you compile with -O2 or below, you don't. Passing
> -xbuiltin=%none, any of the -xno*lib or -xc99 etc options don't seem to
> change anything. With older versions of Sun/Solaris Studio, it never
> seems to call _memset.
>
> The Oracle documentation on this is puzzling to me:
>
>
> It says "The following table lists runtime support functions that may be
> called in code compiled to run in the Solaris kernel, as a result of
> source code translation by the C compiler." the table includes _memset,
> _memcpy, et al. Then it says
>
> "Note that some versions of the kernel do not provide _memmove(),
> _memcpy(), or _memset(), but do provide kernel mode analogues of the
> user mode routines memmove(), memcpy(), and memset()."
>
> But it doesn't say how to avoid it. I'm not sure if there's a compiler
> flag we're missing here, or if it's not supported to use -O3 for kernel
> modules, or... ? Or it's just a bug. It's also interesting that this
> doesn't happen on amd64, though I assume that's just because it uses
> different arch-specific optimizations.
>
> I don't know, should I just try to file a bug anyway, or should we try
> to get someone with a support contract to say something?
>
> --
> Andrew Deason
> adea...@sinenomine.net
>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--
Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 18:10:53 -0400 Jeff Blaine wrote: > I then rebooted and got the same result upon trying modload > again. > > I edited: > > src/cf/osconf.m4 > src/libuafs/MakefileProto.SOLARIS.in > src/libafs/MakefileProto.SOLARIS.in Well, you need to re-configure each time (or modify the Makefiles directly). If you look at the command run for afs_dynroot.c you'll see what we're actually running. If there's a -O2 in there and you're still getting the error, then something is wrong. I'll look at running through the whole build process later tonight to see what specifically you need to do, if not that. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
FWIW, I can't get any workaround to work. Iterative
setting of -O to -O2 where I could find it across
various builds got me finally to here where I gave up:
bash-3.00# /usr/sbin/modload
sun4x_510/dest/root.client/usr/vice/etc/modload/libafs64.o
can't load module: Out of memory or no room in system tables
May 31 18:01:47 rcf-afs-test.our.org genunix: [ID 104096 kern.warning]
WARNING: system call missing from bind file
I then rebooted and got the same result upon trying modload
again.
I edited:
src/cf/osconf.m4
src/libuafs/MakefileProto.SOLARIS.in
src/libafs/MakefileProto.SOLARIS.in
On 5/31/2011 2:13 PM, Andrew Deason wrote:
On Tue, 31 May 2011 12:14:31 -0500
Andrew Deason wrote:
Or I can just find it by commenting stuff out and seeing when the
_memset ref goes away. It appears to be this loop that's causing it, in
afs_RebuildDynroot lines 378/379:
for (i = 0; i< NHASHENT; i++)
dirHeader->hashTable[i] = 0;
which makes sense; that's pretty easily optimizable into a memset.
I'll get a simpler demonstration together to submit to Oracle.
Also, Jeff, if you want a quick workaround, you can change -O to -O2 or
just leave out the -O option. I think changing the value of KERN_OPTMZ
in src/cf/osconf.m4 should be enough...
And now I'm not completely sure if this is a bug or if we're just
missing the magic incantation to make this not happen. A simple test
case:
void
foo(short *arr)
{
int i;
for (i = 0; i< 256; i++)
arr[i] = 0;
}
If you compile with 'cc foo.c -c -o foo.o -O3', you get a reference to
_memset. If you compile with -O2 or below, you don't. Passing
-xbuiltin=%none, any of the -xno*lib or -xc99 etc options don't seem to
change anything. With older versions of Sun/Solaris Studio, it never
seems to call _memset.
The Oracle documentation on this is puzzling to me:
It says "The following table lists runtime support functions that may be
called in code compiled to run in the Solaris kernel, as a result of
source code translation by the C compiler." the table includes _memset,
_memcpy, et al. Then it says
"Note that some versions of the kernel do not provide _memmove(),
_memcpy(), or _memset(), but do provide kernel mode analogues of the
user mode routines memmove(), memcpy(), and memset()."
But it doesn't say how to avoid it. I'm not sure if there's a compiler
flag we're missing here, or if it's not supported to use -O3 for kernel
modules, or... ? Or it's just a bug. It's also interesting that this
doesn't happen on amd64, though I assume that's just because it uses
different arch-specific optimizations.
I don't know, should I just try to file a bug anyway, or should we try
to get someone with a support contract to say something?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
Also, Jeff, if you want a quick workaround, you can change -O to -O2 or just leave out the -O option. I think changing the value of KERN_OPTMZ in src/cf/osconf.m4 should be enough... That didn't do it for me. Trying now with -O2 in MakefileProto.SOLARIS.in instead of -O ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 12:14:31 -0500
Andrew Deason wrote:
> Or I can just find it by commenting stuff out and seeing when the
> _memset ref goes away. It appears to be this loop that's causing it, in
> afs_RebuildDynroot lines 378/379:
>
> for (i = 0; i < NHASHENT; i++)
> dirHeader->hashTable[i] = 0;
>
> which makes sense; that's pretty easily optimizable into a memset.
>
> I'll get a simpler demonstration together to submit to Oracle.
Also, Jeff, if you want a quick workaround, you can change -O to -O2 or
just leave out the -O option. I think changing the value of KERN_OPTMZ
in src/cf/osconf.m4 should be enough...
And now I'm not completely sure if this is a bug or if we're just
missing the magic incantation to make this not happen. A simple test
case:
void
foo(short *arr)
{
int i;
for (i = 0; i < 256; i++)
arr[i] = 0;
}
If you compile with 'cc foo.c -c -o foo.o -O3', you get a reference to
_memset. If you compile with -O2 or below, you don't. Passing
-xbuiltin=%none, any of the -xno*lib or -xc99 etc options don't seem to
change anything. With older versions of Sun/Solaris Studio, it never
seems to call _memset.
The Oracle documentation on this is puzzling to me:
It says "The following table lists runtime support functions that may be
called in code compiled to run in the Solaris kernel, as a result of
source code translation by the C compiler." the table includes _memset,
_memcpy, et al. Then it says
"Note that some versions of the kernel do not provide _memmove(),
_memcpy(), or _memset(), but do provide kernel mode analogues of the
user mode routines memmove(), memcpy(), and memset()."
But it doesn't say how to avoid it. I'm not sure if there's a compiler
flag we're missing here, or if it's not supported to use -O3 for kernel
modules, or... ? Or it's just a bug. It's also interesting that this
doesn't happen on amd64, though I assume that's just because it uses
different arch-specific optimizations.
I don't know, should I just try to file a bug anyway, or should we try
to get someone with a support contract to say something?
--
Andrew Deason
adea...@sinenomine.net
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] patch : AFS-Monitor (Perl)
In case Alf never gets to integrating this patch and
releasing 0.3.3, here is what is needed to get
AFS-Monitor to *build* with modern OpenAFS. I have
not tested anything other than building yet, and I
am not a Perl extension author of any sort.
Original is here:
http://www.cpan.org/authors/id/A/AL/ALFW/
Or here, though this may go away at some point
as I understand he has changed jobs:
http://www.slac.stanford.edu/~alfw/AFS-Monitor/
diff -r -u AFS-Monitor-0.3.2/src/Monitor.xs AFS-Monitor-0.3.3/src/Monitor.xs
--- AFS-Monitor-0.3.2/src/Monitor.xs2006-09-19 14:00:50.01000 -0400
+++ AFS-Monitor-0.3.3/src/Monitor.xs2011-05-31 13:32:48.01000 -0400
@@ -164,7 +164,7 @@
*/
static void
-myPrintTheseStats(HV *RXSTATS, struct rx_stats *rxstats)
+myPrintTheseStats(HV *RXSTATS, struct rx_statistics *rxstats)
{
HV *PACKETS;
HV *TYPE;
@@ -8910,9 +8910,9 @@
warn("WARNING: Server doesn't support retrieval of Rx
statistics\n");
}
else {
-struct rx_stats rxstats;
+struct rx_statistics rxstats;
-/* should gracefully handle the case where rx_stats grows */
+/* should gracefully handle the case where rx_statistics grows */
code = rx_GetServerStats(s, host, port, &rxstats,
&supportedStatValues);
if (code < 0) {
sprintf(buffer, "rxstats call failed with code %d", code);
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS running on CentOS vs. Scientific Linux
Hi everyone, Currently, we are running our cell on CentOS, but looking into possibly moving towards Scientific Linux. Would love to hear your opinions and recommendations. Please let me know if I should be asking this question on another list. Thank you! Asya___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 12:06:11 -0500 Andrew Deason wrote: > It's hard to tell where the reference is coming from, though. Is there > any way to get nm or something else to tell me the address for what > instructions would be translated to a _memset call? Or I can just find it by commenting stuff out and seeing when the _memset ref goes away. It appears to be this loop that's causing it, in afs_RebuildDynroot lines 378/379: for (i = 0; i < NHASHENT; i++) dirHeader->hashTable[i] = 0; which makes sense; that's pretty easily optimizable into a memset. I'll get a simpler demonstration together to submit to Oracle. -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] modload failing, Sol10 SPARC, 1.4.14
Could _memset be defined in one of the Sun header files on Jeff's computer?
cd /usr/include
find . -type f -exec grep _memset {} \; -print
Does not show it on mine.
# cd /usr/include/
# find . -type f | xargs grep -l _memset
./mlib_sys_proto.h
./libpng10/png.h
./libpng10/pngconf.h
./libpng12/png.h
./libpng12/pngconf.h
./unicode/urename.h
./unicode/ustring.h
./firefox/Containers.h
./firefox/Native.h
./firefox/RegAlloc.h
./firefox/avmplus.h
./firefox/mozpngconf.h
./firefox/png.h
./firefox/pngconf.h
#
FWIW, this is a brand new Solaris 10 09/10 install with
all "Recommended and Security" patches installed via
Patch Check Advanced.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14
On Tue, 31 May 2011 11:50:43 -0500 "Douglas E. Engert" wrote: > I can use Sun Studio 12 on Solaris 10, without > the problem. The compiler was installed originally > on Solaoris 9 in I can see the problem on my Solaris 10 box if I install the newest SUNWspro. My guess is it's translating some C operation into a memset, and for some reason it goes for _memset, and it's a bug in some newish version of Solaris Studio. afs_dynroot.o (for me anyway) has references to both memset and _memset; if I comment out all of the explicit calls to memset, the memset reference goes away but the _memset reference stays. It's hard to tell where the reference is coming from, though. Is there any way to get nm or something else to tell me the address for what instructions would be translated to a _memset call? -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] modload failing, Sol10 SPARC, 1.4.14
I can use Sun Studio 12 on Solaris 10, without
the problem. The compiler was installed originally
on Solaoris 9 in
On 5/31/2011 10:06 AM, Derrick Brashear wrote:2007
Worked with Jeff offline on this. So,
1) *only* afs_dynroot.o has the reference to _memset. no other object
does. other objects reference memset, and rx_knet references
bzero also.
2) the preprocessed output of afs_dynroot.o, using the cc command
libafs uses, includes only:
I get the same thing you get without having to add the -xbuiltin=
using Sun Studio 12 on Solaris 10. The compiler was installed originally
on Solaris 9, so:
% ./cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-02 2007/11/27
grep memset /tmp/memset
extern void *memset(void *, int, size_t);
extern void *memset(void *, int, size_t);
memset(cellHosts, 0, sizeof(cellHosts));
memset(status, 0, sizeof(struct AFSFetchStatus));
memset(status, 0, sizeof(struct AFSFetchStatus));
That's from:
/opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src
-I/var/tmp/openafs-1.4.14/src/afs
-I/var/tmp/openafs-1.4.14/src/afs/SOLARIS
-I/var/tmp/openafs-1.4.14/src/config
-I/var/tmp/openafs-1.4.14/src/rx/SOLARIS
-I/var/tmp/openafs-1.4.14/src/rxkad
-I/var/tmp/openafs-1.4.14/src/rxkad/domestic
-I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src
-I/var/tmp/openafs-1.4.14/src/afs
-I/var/tmp/openafs-1.4.14/src/afs/SOLARIS
-I/var/tmp/openafs-1.4.14/src/util
-I/var/tmp/openafs-1.4.14/src/rxkad
-I/var/tmp/openafs-1.4.14/src/config
-I/var/tmp/openafs-1.4.14/src/fsint
-I/var/tmp/openafs-1.4.14/src/vlserver
-I/var/tmp/openafs-1.4.14/include
-I/var/tmp/openafs-1.4.14/include/afs -O -I. -I..
-I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE
-DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64
-xbuiltin=%none-o afs_dynroot.o -c
/var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c
transmuted to:
/opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src
-I/var/tmp/openafs-1.4.14/src/afs
-I/var/tmp/openafs-1.4.14/src/afs/SOLARIS
-I/var/tmp/openafs-1.4.14/src/config
-I/var/tmp/openafs-1.4.14/src/rx/SOLARIS
-I/var/tmp/openafs-1.4.14/src/rxkad
-I/var/tmp/openafs-1.4.14/src/rxkad/domestic
-I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src
-I/var/tmp/openafs-1.4.14/src/afs
-I/var/tmp/openafs-1.4.14/src/afs/SOLARIS
-I/var/tmp/openafs-1.4.14/src/util
-I/var/tmp/openafs-1.4.14/src/rxkad
-I/var/tmp/openafs-1.4.14/src/config
-I/var/tmp/openafs-1.4.14/src/fsint
-I/var/tmp/openafs-1.4.14/src/vlserver
-I/var/tmp/openafs-1.4.14/include
-I/var/tmp/openafs-1.4.14/include/afs -O -I. -I..
-I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE
-DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64
-xbuiltin=%none -E /var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c
So I'm not sure what I'm missing.
Could _memset be defined in one of the Sun header files on Jeff's computer?
cd /usr/include
find . -type f -exec grep _memset {} \; -print
Does not show it on mine.
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] modload failing, Sol10 SPARC, 1.4.14
Maybe this is something? /usr/lib/abi/appcert/* # grep memset etc.alt etc.scoped etc.alt:ALT_USAGE:inadvertant_static_linking:static linking inadevertantly brings in private symbols:*:__getcontext|__sigaction|__threaded|_bufsync|_cerror|_dgettext|_doprnt|_doscan|_ecvt|_fcvt|_findbuf|_findiop|_getsp|_memcmp|_memmove|_memset|_mutex_unlock|_psignal|_realbufend|_setbufend|_siguhandler|_smbuf|_thr_getspecific|_thr_keycreate|_thr_main|_thr_setspecific|_xflsbuf|gtty|stty: etc.scoped:SCOPED_SYMBOL|SunOS_5.6|ld.so.1|_memset etc.scoped:SCOPED_SYMBOL|SunOS_5.6|ld.so.1|memset # On 5/31/2011 11:06 AM, Derrick Brashear wrote: Worked with Jeff offline on this. So, 1) *only* afs_dynroot.o has the reference to _memset. no other object does. other objects reference memset, and rx_knet references bzero also. 2) the preprocessed output of afs_dynroot.o, using the cc command libafs uses, includes only: grep memset /tmp/memset extern void *memset(void *, int, size_t); extern void *memset(void *, int, size_t); memset(cellHosts, 0, sizeof(cellHosts)); memset(status, 0, sizeof(struct AFSFetchStatus)); memset(status, 0, sizeof(struct AFSFetchStatus)); That's from: /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/rx/SOLARIS -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/rxkad/domestic -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/fsint -I/var/tmp/openafs-1.4.14/src/vlserver -I/var/tmp/openafs-1.4.14/include -I/var/tmp/openafs-1.4.14/include/afs -O -I. -I.. -I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64 -xbuiltin=%none-o afs_dynroot.o -c /var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c transmuted to: /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/rx/SOLARIS -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/rxkad/domestic -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/fsint -I/var/tmp/openafs-1.4.14/src/vlserver -I/var/tmp/openafs-1.4.14/include -I/var/tmp/openafs-1.4.14/include/afs -O -I. -I.. -I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64 -xbuiltin=%none -E /var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c So I'm not sure what I'm missing. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: Help: Cannot execute pts createuser
On Wed, 1 Jun 2011 00:22:49 +0800 Lee Eric wrote: > [root@server ~]# pts createuser -name admin -noauth > pts: Permission denied ; unable to create user admin > [root@server ~]# pts createuser -name admin -id 1 -noauth > pts: Entry for id already exists ; unable to create user admin with id 1 > [root@server ~]# > > Could anyone show me some tips to fix that? Well, you're trying to add a user while unauthenticated (-noauth); usually you need to be authenticated as an administrator in order to add users. So, acquire admin credentials, or try running with -localauth instead of -noauth. Are you following a guide or something? If so, what exactly did it say to do? -- Andrew Deason adea...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Help: Cannot execute pts createuser
> Date:Wed, 01 Jun 2011 00:22:49 +0800 > To: OpenAFS > From:Lee Eric > Subject: [OpenAFS] Help: Cannot execute pts createuser > > Hi, > > I'm use Fedora 14 x86_64 and while I'm adding a Production Database > entry for the admin user. > > > [root@server ~]# pts createuser -name admin -noauth > pts: Permission denied ; unable to create user admin > [root@server ~]# pts createuser -name admin -id 1 -noauth > pts: Entry for id already exists ; unable to create user admin with id 1 > [root@server ~]# > > Could anyone show me some tips to fix that? > > Thanks. > > Eric > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info Hopefully you mean 'protection' and not 'production'. At least, I hope you haven't yet created anything else that you care about in the pt database. If you have things running "-noauth", undo that; this was an ancient transarc kludge that needs to be eradicated from the install directions. to initialize the database, make sure ptserver is not running, then as root on the db server, rm -f /var/lib/openafs/db/*.DB* pt_util -w https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Help: Cannot execute pts createuser
Hi, I'm use Fedora 14 x86_64 and while I'm adding a Production Database entry for the admin user. [root@server ~]# pts createuser -name admin -noauth pts: Permission denied ; unable to create user admin [root@server ~]# pts createuser -name admin -id 1 -noauth pts: Entry for id already exists ; unable to create user admin with id 1 [root@server ~]# Could anyone show me some tips to fix that? Thanks. Eric ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] modload failing, Sol10 SPARC, 1.4.14
Worked with Jeff offline on this. So, 1) *only* afs_dynroot.o has the reference to _memset. no other object does. other objects reference memset, and rx_knet references bzero also. 2) the preprocessed output of afs_dynroot.o, using the cc command libafs uses, includes only: grep memset /tmp/memset extern void *memset(void *, int, size_t); extern void *memset(void *, int, size_t); memset(cellHosts, 0, sizeof(cellHosts)); memset(status, 0, sizeof(struct AFSFetchStatus)); memset(status, 0, sizeof(struct AFSFetchStatus)); That's from: /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/rx/SOLARIS -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/rxkad/domestic -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/fsint -I/var/tmp/openafs-1.4.14/src/vlserver -I/var/tmp/openafs-1.4.14/include -I/var/tmp/openafs-1.4.14/include/afs -O -I. -I.. -I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64 -xbuiltin=%none-o afs_dynroot.o -c /var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c transmuted to: /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/rx/SOLARIS -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/rxkad/domestic -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src -I/var/tmp/openafs-1.4.14/src/afs -I/var/tmp/openafs-1.4.14/src/afs/SOLARIS -I/var/tmp/openafs-1.4.14/src/util -I/var/tmp/openafs-1.4.14/src/rxkad -I/var/tmp/openafs-1.4.14/src/config -I/var/tmp/openafs-1.4.14/src/fsint -I/var/tmp/openafs-1.4.14/src/vlserver -I/var/tmp/openafs-1.4.14/include -I/var/tmp/openafs-1.4.14/include/afs -O -I. -I.. -I/var/tmp/openafs-1.4.14/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -m64 -xbuiltin=%none -E /var/tmp/openafs-1.4.14/src/afs/afs_dynroot.c So I'm not sure what I'm missing. -- Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
