>> There is a small error in the compilation of /sys/src/cmd/ip/snoopy
>> (for the ARM, I expect the same for the 386 ... and it is):
>>
>> mk snoopy
>> 5c -FTVw aoemask.c
>> ip/snoopy/aoemask.c:42 name not declared: aoerr
>> mk: 5c -FTVw aoemask.c : exit status=rc 5630: 5c 56
>There's a good chance your /tmp issue is not permissions,
>but a lack of /tmp being mounted. If your hostowner
>doesn't have a lib/profile or its lib/profile doesn't
>mount /tmp, then you won't be able to write anything
>to it.
Ah! That's probably it. My hostowner definitely doesn't have a pro
> The file servers that maintain on-disk file systems
> like kfs, fossil, kenfs, etc. all do use groups in
> the expected way.
yes. but there are obscure exceptions.
dossrv is fully updatable, but doesn't bother with groups.
but of course that's cheating. fat doesn't even support users.
and it
> I'll check the permissions on /tmp, and I bet you're right
> there.
There's a good chance your /tmp issue is not permissions,
but a lack of /tmp being mounted. If your hostowner
doesn't have a lib/profile or its lib/profile doesn't
mount /tmp, then you won't be able to write anything
to it. As
> Wasn't that what we found just last week regarding the
> /dev/sd00/nvram thing? This is
> on native Plan 9, (er, under VMware), not 9vx or anything
> like that. The filesystem is
> fossil, not kfs.
The file servers that maintain on-disk file systems
like kfs, fossil, kenfs, etc. all do use gro
I think it worths to mention: for convenience, run as hostworner once:
cd
mkdir lib/replica
cp -x /dist/replica/network lib/replica/sys
Since then, pulls can be done as easy as "replica/pull -v sys"
- Yaroslav
>> sys/src/9/omap/screen.c: not replicated; will not update
>
> I wonder if your replica databases have got in a mess? Somone whith more
> nous of replicas internals may be able to help there.
>
> -Steve
Local replica DB mismatches can be handled like pull conflicts: with
either -s path or -c path
>I don't believe you can simply switch fossil into and out of allow mode,
>you can specify -P to open to disable permission checking (enable allow)
>see fossilcons(8) but that would require a reboot.
>
>As I described before, this should not be necessary, and is not for me.
>just run bull as hostow
> Wasn't that what we found just last week regarding the /dev/sd00/nvram thing?
> This is
> on native Plan 9, (er, under VMware), not 9vx or anything like that. The
> filesystem is
> fossil, not kfs.
i think you are confusing the block filesystem served by #S, which
does not do (real) group ch
> >you may wish to put your fs into allow mode for pull.
> You can do that on fossil? I thought you had to have kfs for that?
I don't believe you can simply switch fossil into and out of allow mode,
you can specify -P to open to disable permission checking (enable allow)
see fossilcons(8) but tha
>this is almost certainly incorrect. (you don't mention you're using 9vx' #Z.)
>plan 9 fileservers that store files on disk (fossil, kfs, kenfs, cwfs, etc) do
>maintain their own groups. you may wish to put your fs into allow mode
>for pull.
>
>it's plan 9 file servers living in the local kernel,
The most effective way I've found to build from sources is to use
mercurial. The second most effective way is replica.
I have found I quite enjoy building from and hacking on a sources tree
backed by mercurial. YMMV.
ron
On Thu, Oct 21, 2010 at 1:23 AM, Benjamin Huntsman
wrote:
>bootes is a member of the sys group, but
> as we discussed previously, that won't be honored in the current
> implementation.
I'm pretty sure we did not say anything like that.
ron
> This is on a combined CPU/auth server, and was run as the hostowner (bootes).
> Are the permissions wrong out-of-the-box? Could this be because some
> directories
> are owned by sys while others by bootes? bootes is a member of the sys
> group, but
> as we discussed previously, that won't be
> There is a small error in the compilation of /sys/src/cmd/ip/snoopy
> (for the ARM, I expect the same for the 386 ... and it is):
>
> mk snoopy
> 5c -FTVw aoemask.c
> ip/snoopy/aoemask.c:42 name not declared: aoerr
> mk: 5c -FTVw aoemask.c : exit status=rc 5630: 5c 5632:
You might want to look at /tmp, you may not have a writable one from
the login. Executing "ramfs" normally takes care of that issue.
I saw the "ratrace.c" error this early morning, but it seems to have
been transient. I guess you ought to try a second time, by then somebody
more savvy than me m
> error: copying /n/boot/386/9load: '/tmp/replica00098100' permission denied
Not somthing as trivial as you have no /tmp? (its usually bound to $home/tmp in
profile).
> So is the proper thing to do to convert a new install to a cpu/file server
> (fossil)
> to change ownership of all files to bo
>there is a pull script in glenda's bin. use that.
>
>- erik
I was giving that a shot, but get a few errors. Looks like it's not pulling
new files:
! sys/src/cmd/ratrace.c: not replicated; will not update
! sys/src/9/kw/devtwsi.c: not replicated; will not update
! sys/src/9/omap/screen.c: not
Hello everyone,
I'm still fairly new to plan9 after only a little over a week of exposure and
intense absorption
into that world. At this point, I'm coming up for air in order to see what the
long time prospects
are. To be honest, I'm not sure, in particular with respect to its life outside
a r
19 matches
Mail list logo
