Re: [9fans] How and where to submit a patch for acme?
On Mar 29, 2011, at 2:45 PM, John Floren wrote: > On Tue, Mar 29, 2011 at 12:17 PM, erik quanstrom > wrote: >>> >> except to talk to russ. >> > > In this case, if you have a bitbucket account, just make a fork of > russ's repo, make the change in your fork, then send Russ a pull > request on bitbucket. and: 9 man codereview
[9fans] encrypting file systems
> I've got a rejected-by-usenix paper somewhere about writing a 9p > encryption fs which you could stack on anything that served 9p: do you have a copy of this paper? did you just rewrite a block-at-a-time? - erik
[9fans] some questions--gsoc
> hi, > i saw some project ideias in the following page::: > http://www.plan9.bell-labs.com/wiki/plan9/gsoc-2011-ideas/index.html > > i liked some project ideias, like :: > Native asn.1 DER encode/decode library > Make a keyboard file server > Create an alternative window manager > > but there are missing some informations like:: the skills the participant > must have, the programming language he must know to be able to do the > project , perhaps some exaples, links to external references, some similar > code , etc except for inferno projects that require limbo, almost all of the code required will be in c. > for the project ideia:::Native asn.1 DER encode/decode library > > i have not uderstood what are the following things::: > Write a native (non-APE) library for encoding and decoding ASN.1 DER data. ape is the plan 9 ansi/posix emulation libraries, compiler, etc. > > what is non-APE, ASN,DER data, , LDAP, RFCs, the rest you can google. - erik
[9fans] some questions--gsoc
hi, i saw some project ideias in the following page::: http://www.plan9.bell-labs.com/wiki/plan9/gsoc-2011-ideas/index.html i liked some project ideias, like :: Native asn.1 DER encode/decode library Make a keyboard file server Create an alternative window manager but there are missing some informations like:: the skills the participant must have, the programming language he must know to be able to do the project , perhaps some exaples, links to external references, some similar code , etc for the project ideia:::Native asn.1 DER encode/decode library i have not uderstood what are the following things::: Write a native (non-APE) library for encoding and decoding ASN.1 DER data. what is non-APE, ASN,DER data, , LDAP, RFCs, i thank you in advance for you answer best regards
Re: [9fans] problem with rminnich's 9vx
On Tue Mar 29 16:07:39 EDT 2011, fors...@terzarima.net wrote: > >also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach) > >structure (depending on if up is set or not), so the maximum sprint > >to something on the stack is always going to be < 4k. > > that's fine, but the sprint is the one from the c library > which needs to support more than that. the normal kernel doesn't use > a special one, which is part of the answer to ron's question. i guess i should have asked more directly, why not pass in an n such that buf+n = largest possible address. e.g ~(uintptr)buf. - erik
Re: [9fans] problem with rminnich's 9vx
On Tue, Mar 29, 2011 at 1:25 PM, Charles Forsyth wrote: >one question is: why does the 9vx environment > make the original version of sprint fail? I'm glad you asked that question :-) I ran out of time to track it down. It's got something to do with how the address space is set up in 32-bit 9vx running in 32-bit emulation on 64-bit ubuntu, and that's as much as I had time for. Note there is no issue on osx, for example. I've gotten used to ubuntu causing these kinds of weird issues over the last five years since they unilaterally started doing things that broke builds for embedded software. But it would still be nice to know what's going on. So if someone can find out ... But the proposed patch, while it works, just feels like the wrong approach to me. I'd rather know more. ron
Re: [9fans] problem with rminnich's 9vx
>I'm still not sure a length limit on the string of 1 Gbyte makes >sense, and I have no idea if 64K is too low, but the 64k-limit patch >does make it all work. I'm going to try to apply it tomorrow and see >what shakes. at some point, a value ep = bp + lim will be formed. if bp+lim is too big, ep will be too small, which will be bad, because the formatting functions will stop too soon. that's why the test is there. one question is: why does the 9vx environment make the original version of sprint fail?
Re: [9fans] problem with rminnich's 9vx
>also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach) >structure (depending on if up is set or not), so the maximum sprint >to something on the stack is always going to be < 4k. that's fine, but the sprint is the one from the c library which needs to support more than that. the normal kernel doesn't use a special one, which is part of the answer to ron's question.--- Begin Message --- On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote: > in fact, even 64k might be too big a value for the given buf if it's near the > top of memory (eg, a local variable on a stack that's in high memory); > the PowerPC reference in the original comment is misleading because that > was just a particular system where the general problem appeared. if that's the case, isn't this already a bug. the stack doesn't go past the end of memory, so how could sprint(buf, "x") not overwrite junk past the end of the stack anyway? also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach) structure (depending on if up is set or not), so the maximum sprint to something on the stack is always going to be < 4k. - erik--- End Message ---
Re: [9fans] problem with rminnich's 9vx
On Tue, Mar 29, 2011 at 12:05 PM, erik quanstrom wrote: > On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote: >> in fact, even 64k might be too big a value for the given buf if it's near the >> top of memory (eg, a local variable on a stack that's in high memory); >> the PowerPC reference in the original comment is misleading because that >> was just a particular system where the general problem appeared. > > if that's the case, isn't this already a bug. the stack doesn't go past > the end of memory, so how could sprint(buf, "x") not overwrite junk > past the end of the stack anyway? > > also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach) > structure (depending on if up is set or not), so the maximum sprint > to something on the stack is always going to be < 4k. This discussion is why I did not want to apply that patch, even though it helps. I just want to make sure I understand the issues and was not convinced I did. ron
Re: [9fans] How and where to submit a patch for acme?
On Tue, Mar 29, 2011 at 12:17 PM, erik quanstrom wrote: >> On Tue, 29 Mar 2011 10:58:55 -0700 John Floren wrote: >> >On Tue, Mar 29, 2011 at 10:46 AM, John A. Grahor wrote: >> >>What form of diff and relative to what? >> >> >> >>Where to post? >> >> >> >> >> > >> >man 1 patch >> > >> Sorry, I was too terse. I'm using plan9port. (9 man 1 patch) == nothing. >> >> Is this the wrong list for plan9port? > > plan9port is in hg on bitbucket. i'm not sure how to > submit patches, except to talk to russ. > > - erik > > In this case, if you have a bitbucket account, just make a fork of russ's repo, make the change in your fork, then send Russ a pull request on bitbucket. John
Re: [9fans] How and where to submit a patch for acme?
> On Tue, 29 Mar 2011 10:58:55 -0700 John Floren wrote: > >On Tue, Mar 29, 2011 at 10:46 AM, John A. Grahor wrote: > >>What form of diff and relative to what? > >> > >>Where to post? > >> > >> > > > >man 1 patch > > > Sorry, I was too terse. I'm using plan9port. (9 man 1 patch) == nothing. > > Is this the wrong list for plan9port? plan9port is in hg on bitbucket. i'm not sure how to submit patches, except to talk to russ. - erik
[9fans] quanstro.net back up (note space)
the great techs from at&t came today. the 24-pair termination right in front of the house was blow apart, and the termination pcb was 25% vaporized. i wish i had a picture. the techs fixed that like nothing, and found few other blown connections. my dsl modem had a hole in the pcb. amazing that the thing still booted. thumbs up for caymen. so i had to replace that and fight with the stupid new modem, that's much less impressive. so score it: 1 termination point, 1 phone jack, 1 dsl modem, one server. so assuming i haven't missed anything, quanstro.net should be back up. please send me email off list if you think that's not the case. - erik
Re: [9fans] problem with rminnich's 9vx
On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote: > in fact, even 64k might be too big a value for the given buf if it's near the > top of memory (eg, a local variable on a stack that's in high memory); > the PowerPC reference in the original comment is misleading because that > was just a particular system where the general problem appeared. if that's the case, isn't this already a bug. the stack doesn't go past the end of memory, so how could sprint(buf, "x") not overwrite junk past the end of the stack anyway? also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach) structure (depending on if up is set or not), so the maximum sprint to something on the stack is always going to be < 4k. - erik
Re: [9fans] How and where to submit a patch for acme?
On Tue, 29 Mar 2011 10:58:55 -0700 John Floren wrote: On Tue, Mar 29, 2011 at 10:46 AM, John A. Grahor wrote: What form of diff and relative to what? Where to post? man 1 patch Sorry, I was too terse. I'm using plan9port. (9 man 1 patch) == nothing. Is this the wrong list for plan9port?
Re: [9fans] diff problem
> So I guess I must change BUF and MAXLINELEN. But shouldn't these > defines be ideally at one place?; also they have no comments... :( > Wouldn't it be nice to have the limits mentioned (automatically, say > during compilation process) in the man page? Or, would it be difficult > to get rid of any such limits? i didn't spend much time looking at the code, but if you really care, i would recommend reading a line-at-a-time into a malloc'd buffer. malloc is slow, but not slow enough to matter. it might be worth fixing, but any such fix shouldn't result in more complicated code, or yet-another constant. - erik
Re: [9fans] How and where to submit a patch for acme?
On Tue, Mar 29, 2011 at 10:46 AM, John A. Grahor wrote: > What form of diff and relative to what? > > Where to post? > > man 1 patch
[9fans] How and where to submit a patch for acme?
What form of diff and relative to what? Where to post?
Re: [9fans] diff problem
On 29 March 2011 18:45, erik quanstrom wrote:
> your problem is that you have a line that exceeds diff's line-length limits
> of 4096 characters:
>
> 6: !cat /mail/fs/mbox/323/3/body.txt|awk 'length($0)>4096 {print NR " "
> length($0)}'
> 33 4122
>
> - erik
aha. thanks!
But how is it? Does the linux's diff also have some limit, only
higher, or can it adapt to any line lenght?
Also, having bumped into problem like this, I guess I have to
recompile. But how can I know which parameters to change?
Quickly going through the (now plan9; not p9p) source I see several
numbers scattered in the files:
#define BUF 4096 in diffreg.c
#define MAXPATHLEN 1024 in diff.h
#define MAXLINELEN 4096 in diffio.c
#define HALFLONG 16
So I guess I must change BUF and MAXLINELEN. But shouldn't these
defines be ideally at one place?; also they have no comments... :(
Wouldn't it be nice to have the limits mentioned (automatically, say
during compilation process) in the man page? Or, would it be difficult
to get rid of any such limits?
Thanks
Ruda
Re: [9fans] problem with rminnich's 9vx
My bet here is that if you build yiyus or ron tree and force 32-bit, it will fail on a 64-bit system, no idea why. if you build with 64-bit on yiyus tree, it will work. In other words, I think the issue crops up on 32-bit 9vx on 64-bit environments. At least that is how it seems to work. I'm still not sure a length limit on the string of 1 Gbyte makes sense, and I have no idea if 64K is too low, but the 64k-limit patch does make it all work. I'm going to try to apply it tomorrow and see what shakes. ron
Re: [9fans] diff problem
your problem is that you have a line that exceeds diff's line-length limits
of 4096 characters:
6: !cat /mail/fs/mbox/323/3/body.txt|awk 'length($0)>4096 {print NR " "
length($0)}'
33 4122
- erik
Re: [9fans] problem with rminnich's 9vx
2011/3/29 ron minnich : > On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret > wrote: >> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that >> patch, I think that means Yiyus' doesn't have it either. And yet, >> Yiyus' works for me, so I doubt this bug was the culprit for me. More >> like a 64 bits issue as Yiyus mentionned earlier, no? > > well, actually, it's more like yiyus forked mine long ago and then we > trade patches ... so it's not clear what's going on here. Did you look > to see if yiyus took that patch? > I didn't merge your last changes to force 32 bits. I planned to do it but I didn't. That's the only difference between your repository and mine, and somebody in irc said he had seen problems in 64 bits with your last version, so I thought there could be something wrong. I agree we have to arrange things better. -- - yiyus || JGL .
Re: [9fans] problem with rminnich's 9vx
in fact, even 64k might be too big a value for the given buf if it's near the top of memory (eg, a local variable on a stack that's in high memory); the PowerPC reference in the original comment is misleading because that was just a particular system where the general problem appeared.
Re: [9fans] problem with rminnich's 9vx
>+ n = vsnprint(buf, 65536, fmt, args); ... >Note the len = 1 << 30; why was that ever done? I never figured that out there is nothing to limit the length of a string to 64k bytes
Re: [9fans] problem with rminnich's 9vx
On Tue, Mar 29, 2011 at 6:09 PM, ron minnich wrote: > On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret > wrote: >> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that >> patch, I think that means Yiyus' doesn't have it either. And yet, >> Yiyus' works for me, so I doubt this bug was the culprit for me. More >> like a 64 bits issue as Yiyus mentionned earlier, no? > > well, actually, it's more like yiyus forked mine long ago and then we > trade patches ... so it's not clear what's going on here. Did you look > to see if yiyus took that patch? Yes I looked, it doesn't have it. https://bitbucket.org/yiyus/vx32/src/398d27a1f253/src/9vx/a/fmt.c > I run 9vx on 64-bit boxes all the time. One thing I do know is that > ubuntu keeps adding things to the libraries and compiler, so: what > version of ubuntu? 10.04.2 > I tend to trust Christoph's diagnosis on this one but ... and you were right to, because I've just tried it and it also works. so both yours with Christoph's patch and yiyus's without it do, 2 different ways to fix the problem. :)
Re: [9fans] problem with rminnich's 9vx
On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret wrote: > Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that > patch, I think that means Yiyus' doesn't have it either. And yet, > Yiyus' works for me, so I doubt this bug was the culprit for me. More > like a 64 bits issue as Yiyus mentionned earlier, no? well, actually, it's more like yiyus forked mine long ago and then we trade patches ... so it's not clear what's going on here. Did you look to see if yiyus took that patch? I run 9vx on 64-bit boxes all the time. One thing I do know is that ubuntu keeps adding things to the libraries and compiler, so: what version of ubuntu? I tend to trust Christoph's diagnosis on this one but ... ron
Re: [9fans] problem with rminnich's 9vx
Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that patch, I think that means Yiyus' doesn't have it either. And yet, Yiyus' works for me, so I doubt this bug was the culprit for me. More like a 64 bits issue as Yiyus mentionned earlier, no? On Tue, Mar 29, 2011 at 5:06 PM, Christoph Lohmann <2...@r-36.net> wrote: > Hello, > > Mathieu Lonjaret wrote: >> >> this last error keeps on repeating. >> as a plan 9 tree I'm using the same old one that I kept using with rsc's >> 9vx (minimal tree provided by rsc, and later filled with more plan 9 >> stuff), could that be the issue? if yes, what do you guys for a tree >> with ron's 9vx? > > the bug is easy to solve [0]. Ron didn't integrate my patch > for this one for a long time, so I started my own repository > of 9vx. > > I tried to solve the problem by resolving all sprint() occur- > ences in the Plan 9 kernel and that way in 9vx too. The patch > wasn't accepted; sprint() needs to be fixed. > > > Sincerely, > > Christoph Lohmann > > [0] > http://git.r-36.net/vx32/commit/?id=d6e5c080a23fcb914b740db48573305f3712eba0 > >
Re: [9fans] problem with rminnich's 9vx
This one is extremely weird.
On Tue, Mar 29, 2011 at 2:00 AM, Mathieu Lonjaret
wrote:
> Hi all,
>
> this is probably trivial; this is what I get when trying to start 9vx:
>
> Warning! factotum can't protect itself from debugging: '#p/5' file does not
> exist
> init: warning: can't open #p/2/ctl: '#p/2' file does not exist
If #p does not work, well! things are seriously wrong. Do you ever get
an rc prompt?
Oh, I see; it's the ubuntu + sprintf problem. I should have taken
Christoph's patch, sorry about that; my fault.
As to your other questions. There's no real reason to build 9vx as a
64-bit binary, and it causes a lot of headaches, so I stick with a
32-bit version nowadays; also, I build all my binaries using my
sysfromiso repo as a starting point. In fact I build all my arm
kernels on 9vx using sysfromiso and use 9vx as the server for the root
file system for the ARMs. In spite of everything I much prefer hg to
replica.
We need a better way to keep 9vx going than just "Ron's version" or
"Joe's version" or whatever. Certainly patches should not just be
directed to me. I don't see the harm in bringing the discussions to
this list.
Here's the patch in question.
sprint(char *buf, char *fmt, ...)
{
int n;
- uint len;
va_list args;
- len = 1<<30; /* big number, but sprint is deprecated anyway */
- /*
-* on PowerPC, the stack is near the top of memory, so
-* we must be sure not to overflow a 32-bit pointer.
-*/
- if(buf+len < buf)
- len = -(uintptr)buf-1;
-
va_start(args, fmt);
- n = vsnprint(buf, len, fmt, args);
+ n = vsnprint(buf, 65536, fmt, args);
va_end(args);
return n;
}
Note the len = 1 << 30; why was that ever done? I never figured that
out so was never sure about the implications of this patch. Anybody
know?
thanks
ron
Re: [9fans] problem with rminnich's 9vx
Hello, Mathieu Lonjaret wrote: this last error keeps on repeating. as a plan 9 tree I'm using the same old one that I kept using with rsc's 9vx (minimal tree provided by rsc, and later filled with more plan 9 stuff), could that be the issue? if yes, what do you guys for a tree with ron's 9vx? the bug is easy to solve [0]. Ron didn't integrate my patch for this one for a long time, so I started my own repository of 9vx. I tried to solve the problem by resolving all sprint() occur- ences in the Plan 9 kernel and that way in 9vx too. The patch wasn't accepted; sprint() needs to be fixed. Sincerely, Christoph Lohmann [0] http://git.r-36.net/vx32/commit/?id=d6e5c080a23fcb914b740db48573305f3712eba0
Re: [9fans] Encrypting file systems
I've got a rejected-by-usenix paper somewhere about writing a 9p encryption fs which you could stack on anything that served 9p: exportfs, fossil, tarfs, whatever. It essentially attached to a 9p server, you set the key, it encrypted/decrypted the data as it wrote to its server. The neat thing about such an encrypting server is you can stack it anywhere you have 9p server, which is quite fun; you can even stack it over another instance of itself. You don't need to be root to use it. You can pick an arbitrary key and don't have to share it with anyone. And so on. I have no idea where it is at this point. maybe you can take cfs and make encrypting? ron
Re: [9fans] Encrypting file systems
There's two implementations that i know of: one is in russ' contrib, and there another one called cbfs (i think), which is also on contrib, although i don't remember where. The latter version could be russ' implementation with changes, it's been a while since I tried either. Russ' didn't compile at first, there were two variables with the same name iirc.
[9fans] Encrypting file systems
Hello, Back in 2009, someone on this list posted about encrypting /usr on a Plan 9 laptop they had. Does anyone know how to encrypt a file system on Plan 9? (I'm talking about encrypting the storage on disk, not just the network connection to it.) My intuition would be to look for a "crypt" command in the fs(3) driver. But there doesn't seem to be any. (And the man pages suggest that keyfs only stores files 40 bytes in size?) Yes, I know I could export a device from another OS (like Linux), but I'm looking for a native Plan 9 solution. How might one go about encrypting a Plan 9 file system, either at the block level or file level? Thanks! -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] problem with rminnich's 9vx
Good call; yours starts without a problem, thanks. On Tue, Mar 29, 2011 at 11:47 AM, yy wrote: > ron's 9vx and mine are compiled differently in 64bits systems, so you > can try mine and see if there is any difference, but I don't really > know. I don't have any x86_64 system I can use to test 9vx, so please > let me know if things get better (or worse). If you don't want to > download the whole vx32 tree again you can just rollback the last > changes by ron and compile that, the result will be the same. > >> what do you guys for a tree >> with ron's 9vx? > > For testing, I always use a plan9.iso file (a full tree can solve some > problems but I don't think it will solve yours). When I need write > permissions I use a kfs file I filled with the contents of the iso. > > > -- > - yiyus || JGL . >
Re: [9fans] problem with rminnich's 9vx
ron's 9vx and mine are compiled differently in 64bits systems, so you can try mine and see if there is any difference, but I don't really know. I don't have any x86_64 system I can use to test 9vx, so please let me know if things get better (or worse). If you don't want to download the whole vx32 tree again you can just rollback the last changes by ron and compile that, the result will be the same. > what do you guys for a tree > with ron's 9vx? For testing, I always use a plan9.iso file (a full tree can solve some problems but I don't think it will solve yours). When I need write permissions I use a kfs file I filled with the contents of the iso. -- - yiyus || JGL .
Re: [9fans] problem with rminnich's 9vx
I don't know enough about the causes to be of much help. Ron, Yiyus or Russ might know. Noah On Tue, Mar 29, 2011 at 11:25 AM, Mathieu Lonjaret wrote: > Nothing remote or fancy here, just starting 9vx locally (-u glenda -r > plan9vx) after having built it. > However, it is a 64 bits linux and I haven't done anything special or > set any flag when building (cd src; make; make install). Should I? > > On Tue, Mar 29, 2011 at 11:18 AM, Noah Evans wrote: >> I've seen this behavior before, once using 9vx on a remote xsession >> and once when using strace on a (broken) 9vx that was compiled for >> 32bit on a 64bit linux. Are there any mitigating factors that could be >> causing your problem? >> >> Noah >> >> >> >> On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret >> wrote: >>> Hi all, >>> >>> this is probably trivial; this is what I get when trying to start 9vx: >>> >>> Warning! factotum can't protect itself from debugging: '#p/5' file does not >>> exist >>> init: warning: can't open #p/2/ctl: '#p/2' file does not exist >>> >>> init: starting /bin/rc >>> FAILED >>> Warning! auth/factotum can't protect itself from debugging: '#p/64' file >>> does not exist >>> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer >>> init: rc exit status: rio 9: display open >>> >>> init: starting /bin/rc >>> #d/0: rc: .: can't open: '#d/0' file does not exist >>> init: rc exit status: rc 67: error >>> >>> init: starting /bin/rc >>> #d/0: rc: .: can't open: '#d/0' file does not exist >>> init: rc exit status: rc 68: error >>> >>> this last error keeps on repeating. >>> as a plan 9 tree I'm using the same old one that I kept using with rsc's >>> 9vx (minimal tree provided by rsc, and later filled with more plan 9 >>> stuff), could that be the issue? if yes, what do you guys for a tree >>> with ron's 9vx? >>> >>> uname -a: >>> Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 >>> GNU/Linux >>> >>> Cheers, >>> mathieu >>> >>> >>> >> >
Re: [9fans] problem with rminnich's 9vx
Nothing remote or fancy here, just starting 9vx locally (-u glenda -r plan9vx) after having built it. However, it is a 64 bits linux and I haven't done anything special or set any flag when building (cd src; make; make install). Should I? On Tue, Mar 29, 2011 at 11:18 AM, Noah Evans wrote: > I've seen this behavior before, once using 9vx on a remote xsession > and once when using strace on a (broken) 9vx that was compiled for > 32bit on a 64bit linux. Are there any mitigating factors that could be > causing your problem? > > Noah > > > > On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret > wrote: >> Hi all, >> >> this is probably trivial; this is what I get when trying to start 9vx: >> >> Warning! factotum can't protect itself from debugging: '#p/5' file does not >> exist >> init: warning: can't open #p/2/ctl: '#p/2' file does not exist >> >> init: starting /bin/rc >> FAILED >> Warning! auth/factotum can't protect itself from debugging: '#p/64' file >> does not exist >> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer >> init: rc exit status: rio 9: display open >> >> init: starting /bin/rc >> #d/0: rc: .: can't open: '#d/0' file does not exist >> init: rc exit status: rc 67: error >> >> init: starting /bin/rc >> #d/0: rc: .: can't open: '#d/0' file does not exist >> init: rc exit status: rc 68: error >> >> this last error keeps on repeating. >> as a plan 9 tree I'm using the same old one that I kept using with rsc's >> 9vx (minimal tree provided by rsc, and later filled with more plan 9 >> stuff), could that be the issue? if yes, what do you guys for a tree >> with ron's 9vx? >> >> uname -a: >> Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 >> GNU/Linux >> >> Cheers, >> mathieu >> >> >> >
Re: [9fans] problem with rminnich's 9vx
I've seen this behavior before, once using 9vx on a remote xsession and once when using strace on a (broken) 9vx that was compiled for 32bit on a 64bit linux. Are there any mitigating factors that could be causing your problem? Noah On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret wrote: > Hi all, > > this is probably trivial; this is what I get when trying to start 9vx: > > Warning! factotum can't protect itself from debugging: '#p/5' file does not > exist > init: warning: can't open #p/2/ctl: '#p/2' file does not exist > > init: starting /bin/rc > FAILED > Warning! auth/factotum can't protect itself from debugging: '#p/64' file does > not exist > rio: can't open display: initdisplay: /dev/draw/new: no frame buffer > init: rc exit status: rio 9: display open > > init: starting /bin/rc > #d/0: rc: .: can't open: '#d/0' file does not exist > init: rc exit status: rc 67: error > > init: starting /bin/rc > #d/0: rc: .: can't open: '#d/0' file does not exist > init: rc exit status: rc 68: error > > this last error keeps on repeating. > as a plan 9 tree I'm using the same old one that I kept using with rsc's > 9vx (minimal tree provided by rsc, and later filled with more plan 9 > stuff), could that be the issue? if yes, what do you guys for a tree > with ron's 9vx? > > uname -a: > Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 > GNU/Linux > > Cheers, > mathieu > > >
[9fans] problem with rminnich's 9vx
Hi all, this is probably trivial; this is what I get when trying to start 9vx: Warning! factotum can't protect itself from debugging: '#p/5' file does not exist init: warning: can't open #p/2/ctl: '#p/2' file does not exist init: starting /bin/rc FAILED Warning! auth/factotum can't protect itself from debugging: '#p/64' file does not exist rio: can't open display: initdisplay: /dev/draw/new: no frame buffer init: rc exit status: rio 9: display open init: starting /bin/rc #d/0: rc: .: can't open: '#d/0' file does not exist init: rc exit status: rc 67: error init: starting /bin/rc #d/0: rc: .: can't open: '#d/0' file does not exist init: rc exit status: rc 68: error this last error keeps on repeating. as a plan 9 tree I'm using the same old one that I kept using with rsc's 9vx (minimal tree provided by rsc, and later filled with more plan 9 stuff), could that be the issue? if yes, what do you guys for a tree with ron's 9vx? uname -a: Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux Cheers, mathieu
