[9fans] 9pfuse adventure

[9fans] 9pfuse adventure

[sqweek]

[-- Attachment #1: Type: text/plain, Size: 6254 bytes --]

 A while ago I ran acme at home to edit files at work using the neat
u9fs over ssh trick[1]. I was impressed with how well it worked, so I
thought I'd try it the other way. But obviously, my work machine isn't
running plan9 so I can't use exactly the same approach.
 Also, my username at home is different to my username at work.
Wouldn't have expected this to give me trouble, but p9p doesn't appear
provide any facility to attach as a different user. So, I modified the
attach strategy to look for a USER environment variable before falling
back on getuser(). I've attached the diff, hopefully I got everything.
 At this point all the connections work:

$ rm `namespace`/wren  #wren is my home server
$ srv sqweek.dnsdojo.org wren
$ USER=sqweek /opt/plan9/src/cmd/o.9p -D ls wren/
<- Tversion tag 0 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tauth tag 0 afid 0 uname sqweek aname <nil>
-> Rauth tag 0 qid (0000000000000001 0 A)
<- Tversion tag 0 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tattach tag 0 fid 0 afid -1 uname sqweek aname
-> Rattach tag 0 qid (0000000000000001 0 d)
<snip>
!adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org
user: sqweek
password:
!
<snip>
d-rwxr-xr-x M 0 root wheel    2048 Feb  3 23:01 etc
d-r-xr-xr-x M 0 root wheel     512 Feb  7 15:14 kern
d-rwxr-xr-x M 0 root wheel     512 Sep  4  2006 proc
<snip>

 wren runs u9fs on netbsd, hence the root/wheel/etc.
 All is good, until I go to mount it using 9pfuse:

$ USER=sqweek /opt/plan9/src/cmd/9pfuse/o.9pfuse -D `namespace`/wren
$HOME/n/wren
<- Tversion tag 0 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tattach tag 0 fid 0 afid -1 uname sqweek aname
-> Rerror tag 0 ename fid unknown or out of range
/opt/plan9/src/cmd/9pfuse/o.9pfuse: fsmount: fid unknown or out of range

 The thing that baffles me the most here (not that it takes much to
baffle my rudimentry understanding of 9p) is that 9p and 9pfuse both
send the exact same Tattach, 9p just precedes it with a Tauth and
suddenly u9fs thinks fid 0 is valid. Isn't the client free to choose
any fid it wants?
 The only reasonable suggestion I can come up with is that 9pfuse
doesn't do auth, and u9fs gives a silly error.
 If I try with srv -a, subsequent attempts to access the socket using
9p or 9pfuse give "authentication failed":

$ rm `namespace`/wren
$ USER=sqweek /opt/plan9/src/cmd/o.srv -D -a sqweek.dnsdojo.org wren
<- Tversion tag 65535 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tauth tag 1 afid 0 uname sqweek aname
-> Rauth tag 1 qid (0000000000000001 0 A)
<- Tread tag 1 fid 0 offset 0 count 4096
-> Rread tag 1 count 25 'p9sk1@sqweek.dnsdojo.org\0'
<- Twrite tag 1 fid 0 offset 0 count 25 'p9sk1 sqweek.dnsdojo.org\0'
-> Rwrite tag 1 count 25
<- Twrite tag 1 fid 0 offset 0 count 8 'eae63a67 1869ea20'
-> Rwrite tag 1 count 8
<- Tread tag 1 fid 0 offset 0 count 141
-> Rread tag 1 count 141 '01737177 65656b00 00000000 00000000 00000000
00000000 00000000 00737177 65656b2e 646e7364 6f6a6f2e 6f726700
00000000 00000000 00000000 00000000'
<- Twrite tag 1 fid 0 offset 0 count 85 '616d745f 42b7fd6d c7ff2799
fb85434e 147a35d6 ed1c60b6 172666fd 5dd47b3d dd1e45ef 90b11ebc
cf207605 d7b5463d 55e0f6b4 75c11a40 1d2dac39 7fb09376'
-> Rwrite tag 1 count 85
<- Tread tag 1 fid 0 offset 0 count 13
-> Rread tag 1 count 13 '7c5995b6 58424643 8a6135e2 00'
$ USER=sqweek /opt/plan9/src/cmd/o.9p -D ls wren/
<- Tversion tag 0 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tauth tag 0 afid 0 uname sqweek aname <nil>
-> Rerror tag 0 ename authentication not required
<- Tattach tag 0 fid 0 afid -1 uname sqweek aname
-> Rerror tag 0 ename authentication failed
/opt/plan9/src/cmd/o.9p: mount: authentication failed
$ USER=sqweek /opt/plan9/src/cmd/9pfuse/o.9pfuse -D `namespace`/wren
$HOME/n/wren
<- Tversion tag 0 msize 8192 version '9P2000'
-> Rversion tag 65535 msize 8192 version '9P2000'
<- Tattach tag 0 fid 0 afid -1 uname sqweek aname
-> Rerror tag 0 ename authentication failed
/opt/plan9/src/cmd/9pfuse/o.9pfuse: fsmount: authentication failed

 Finally, 9pfuse doesn't want to work in general. John Soros reported
a similar problem[2] and on IRC it was discovered we're both running
64-bit linux, which may be related:

$ 9pfuse `namespace`/plumb $HOME/n/:0.0/plumb
$ cd $HOME/n/plumb
$ ls
unexpected open flags 0304000ls: .: Permission denied
$ 9 ls
unexpected open flags 0100000ls: .: Permission denied

 I'm not quite sure what GNU ls is adding into the mix, but 0100000 is
the O_LARGEFILE flag, which ought to get filtered out in _fuseopen:

/usr/local/plan9/src/cmd/9pfuse/main.c:564:        flags &=
~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC);

 But for some reason isn't. It's certainly cpp related:

$ 9c -E main.c |grep 'flags &='
 flags &= ~3;
 flags &= ~(0200000|04000|0|02000000);
  flags &= ~01000;
 flags &= ~3;
 flags &= ~(0200000|04000|0);
 flags &= ~(0100|01000);

 And it turns out /usr/include/bits/fcntl.h #defines O_LARGEFILE to be
0 when __WORDSIZE == 64 (which I verified is the case). So 9pfuse
looks fine, and the question becomes where the hell does ls pull
0100000 from... gdb nails it down to something in the fuse stack:

43              fd = open(name, umode);
(gdb) print umode
$5 = 0
(gdb) step
unexpected open flags 0100000
44         if(fd >= 0){
(gdb) bt
#0  p9open (name=0x4083cc ".", mode=<value optimized out>) at open.c:44
#1  0x0000000000401a0d in ls (s=0x4083cc ".", multi=0) at ls.c:109
#2  0x0000000000401cc5 in p9main (argc=0, argv=0x7fffd9eea508) at ls.c:78
#3  0x00000000004030f9 in main (argc=4228044, argv=0x0) at main.c:10

 Assuming I can trust gdb anyway, which is not always the case *sigh*.
 Well, I don't have the fuse source handy so this adventure will have
to end here.
 Apologies for blogging up 9fans, but I'd appreciate any answers to my
9p questions.
-sqweek

[1] http://cm.bell-labs.com/wiki/plan9/Tip_o'_the_day/index.html
[2] http://lists.cse.psu.edu/archives/9fans/2007-December/056900.html

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: USER.diff --]
[-- Type: text/x-patch; name=USER.diff, Size: 4208 bytes --]

Index: src/cmd/9pserve.c
===================================================================
RCS file: /cvs/plan9/src/cmd/9pserve.c,v
retrieving revision 1.40
diff -u -r1.40 9pserve.c
--- src/cmd/9pserve.c	12 Oct 2007 17:01:00 -0000	1.40
+++ src/cmd/9pserve.c	6 Feb 2008 03:47:36 -0000
@@ -427,7 +427,8 @@
 				}
 				m->tx.afid = xafid;
 				m->tx.aname = xaname;
-				m->tx.uname = getuser();	/* what srv.c used */
+				if((m->tx.uname = getenv("USER")) == nil)
+					m->tx.uname = getuser();	/* what srv.c used */
 				repack(&m->tx, &m->tpkt, c->dotu);
 			}
 			break;
Index: src/cmd/srv.c
===================================================================
RCS file: /cvs/plan9/src/cmd/srv.c,v
retrieving revision 1.6
diff -u -r1.6 srv.c
--- src/cmd/srv.c	12 Oct 2007 17:01:09 -0000	1.6
+++ src/cmd/srv.c	6 Feb 2008 03:47:36 -0000
@@ -136,7 +136,8 @@
 	tx.type = Tauth;
 	tx.tag = 1;
 	tx.afid = afid;
-	tx.uname = getuser();
+	if((tx.uname = getenv("USER")) == nil)
+		tx.uname = getuser();
 	tx.aname = aname;
 	do9p(&tx, &rx);
 	if(rx.type == Rerror){
Index: src/lib9pclient/fs.c
===================================================================
RCS file: /cvs/plan9/src/lib9pclient/fs.c,v
retrieving revision 1.10
diff -u -r1.10 fs.c
--- src/lib9pclient/fs.c	23 Jul 2006 02:55:33 -0000	1.10
+++ src/lib9pclient/fs.c	6 Feb 2008 03:47:40 -0000
@@ -69,14 +69,17 @@
 CFsys*
 fsmount(int fd, char *aname)
 {
+	char *uname;
 	CFsys *fs;
 	CFid *fid;
 
+	if((uname = getenv("USER")) == nil)
+		uname = getuser();
 	fs = fsinit(fd);
 	if(fs == nil)
 		return nil;
 
-	if((fid = fsattach(fs, nil, getuser(), aname)) == nil){
+	if((fid = fsattach(fs, nil, uname, aname)) == nil){
 		_fsunmount(fs);
 		return nil;
 	}
Index: src/lib9pclient/ns.c
===================================================================
RCS file: /cvs/plan9/src/lib9pclient/ns.c,v
retrieving revision 1.4
diff -u -r1.4 ns.c
--- src/lib9pclient/ns.c	13 Jul 2005 10:50:44 -0000	1.4
+++ src/lib9pclient/ns.c	6 Feb 2008 03:47:40 -0000
@@ -38,13 +38,16 @@
 CFsys*
 nsmount(char *name, char *aname)
 {
+	char *uname;
 	CFsys *fs;
 	CFid *fid;
 
+	if((uname = getenv("USER")) == nil)
+		uname = getuser();
 	fs = nsinit(name);
 	if(fs == nil)
 		return nil;
-	if((fid = fsattach(fs, nil, getuser(), aname)) == nil){
+	if((fid = fsattach(fs, nil, uname, aname)) == nil){
 		_fsunmount(fs);
 		return nil;
 	}
Index: src/libauth/fsamount.c
===================================================================
RCS file: /cvs/plan9/src/libauth/fsamount.c,v
retrieving revision 1.1
diff -u -r1.1 fsamount.c
--- src/libauth/fsamount.c	11 Feb 2005 17:01:17 -0000	1.1
+++ src/libauth/fsamount.c	6 Feb 2008 03:47:40 -0000
@@ -8,20 +8,23 @@
 CFsys*
 fsamount(int fd, char *aname)
 {
+	char *uname;
 	CFid *afid, *fid;
 	AuthInfo *ai;
 	CFsys *fs;
 	
+	if((uname = getenv("USER")) == nil)
+		uname = getuser();
 	fs = fsinit(fd);
 	if(fs == nil)
 		return nil;
-	if((afid = fsauth(fs, getuser(), aname)) == nil)
+	if((afid = fsauth(fs, uname, aname)) == nil)
 		goto noauth;
 	ai = fsauth_proxy(afid, amount_getkey, "proto=p9any role=client");
 	if(ai != nil)
 		auth_freeAI(ai);
 noauth:
-	fid = fsattach(fs, afid, getuser(), aname);
+	fid = fsattach(fs, afid, uname, aname);
 	fsclose(afid);
 	if(fid == nil){
 		_fsunmount(fs);
Index: src/libauth/nsamount.c
===================================================================
RCS file: /cvs/plan9/src/libauth/nsamount.c,v
retrieving revision 1.1
diff -u -r1.1 nsamount.c
--- src/libauth/nsamount.c	11 Feb 2005 17:01:18 -0000	1.1
+++ src/libauth/nsamount.c	6 Feb 2008 03:47:40 -0000
@@ -8,20 +8,23 @@
 CFsys*
 nsamount(char *name, char *aname)
 {
+	char *uname;
 	CFid *afid, *fid;
 	AuthInfo *ai;
 	CFsys *fs;
 	
+	if((uname = getenv("USER")) == nil)
+		uname = getuser();
 	fs = nsinit(name);
 	if(fs == nil)
 		return nil;
-	if((afid = fsauth(fs, getuser(), aname)) == nil)
+	if((afid = fsauth(fs, uname, aname)) == nil)
 		goto noauth;
 	ai = fsauth_proxy(afid, amount_getkey, "proto=p9any role=client");
 	if(ai != nil)
 		auth_freeAI(ai);
 noauth:
-	fid = fsattach(fs, afid, getuser(), aname);
+	fid = fsattach(fs, afid, uname, aname);
 	fsclose(afid);
 	if(fid == nil){
 		_fsunmount(fs);

Re: [9fans] 9pfuse adventure

[Russ Cox]

> provide any facility to attach as a different user. So, I modified the
> attach strategy to look for a USER environment variable before falling
> back on getuser(). I've attached the diff, hopefully I got everything.

The name in the attach is almost just a comment.
What matters is the name used inside the authentication
protocol.  (The name in the attach is really only there for
non-authenticated connections.)  So these changes
shouldn't be necessary.

> !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org
> user: sqweek
> password:
> !

This is the problem: you should never be prompted for a
role=speakfor key.  You should be prompted for a role=client key.
If that happened correctly then I think things would have just
worked.  Try pre-loading a role=client key into factotum and
see if that works better.

Russ

[9fans] Can't find CD-ROM

[Chris Saunders]

I am attempting to install Plan9 on Virtual PC.  I boots fine but later when
I attempt to find the CD-ROM I cannot.  Could anyone help?

Regards
Chris Saunders

Re: [9fans] Can't find CD-ROM

[Pietro Gagliardi]

What are you doing when you attempt to find the CD-ROM?

On Feb 11, 2008, at 4:31 AM, Chris Saunders wrote:

> I am attempting to install Plan9 on Virtual PC.  I boots fine but
> later when
> I attempt to find the CD-ROM I cannot.  Could anyone help?
>
> Regards
> Chris Saunders

Re: [9fans] Can't find CD-ROM

[Chris Saunders]

I tried to load it from /dev/sdD0/data which according to the instruction
that I was following is correct.

Regards
Chris Saunders

"Pietro Gagliardi" <pietro10@mac.com> wrote in message
news:1BB187F4-647D-4443-88E0-02400D0F0641@mac.com...
> What are you doing when you attempt to find the CD-ROM?
>
> On Feb 11, 2008, at 4:31 AM, Chris Saunders wrote:
>
>> I am attempting to install Plan9 on Virtual PC.  I boots fine but  later
>> when
>> I attempt to find the CD-ROM I cannot.  Could anyone help?
>>
>> Regards
>> Chris Saunders

Re: [9fans] Can't find CD-ROM

[Eris Discordia]

On Mon, 11 Feb 2008 09:31:15 -0000, Chris Saunders
<evas@mountaincable.net> wrote:

> I am attempting to install Plan9 on Virtual PC.  I boots fine but later
> when
> I attempt to find the CD-ROM I cannot.  Could anyone help?
>
> Regards
> Chris Saunders

I would suggest avoiding Virtual PC for Plan 9. My efforts went nowhere
with an installation of Plan 9 in VPC.

Try QEMU for Windows instead: http://www.h7.dion.ne.jp/~qemu-win/
(download the Windows installer, follow the instructions in the docs and
you will do fine).

Regarding your question (that is, if you want to see for yourself that
Plan 9 will not work on VPC):

1. Make sure you select the correct boot order on VPC's setup (press [del]
key when the virtual machine is starting, then do as you would on your
physical machine).
2. Do gunzip (using WinZIP for example) the Plan 9 ISO image.
3. Make sure you have setup the virtual machine properly. Particularly,
the settings related to your virtual CD-ROM.
4. When the virtual machine is running, try finding the menu item labeled
"capture disc image..." or similar and when asked for an ISO image point
the Open dialog box to the Plan 9 CD image.
5. Make sure you do "release" the ISO image after the installation is done.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Can't find CD-ROM

[Chris Saunders]

As far as I know there is no Open dialog box in Plan9.  Perhaps you could be
a little more explicit.  I have several times brought the instalation up to
this point and the installer suggests that the install image should be at
/dev/sdD0/data.

Regards
Chris Saunders

> 4. When the virtual machine is running, try finding the menu item labeled
> "capture disc image..." or similar and when asked for an ISO image point
> the Open dialog box to the Plan 9 CD image.

Re: [9fans] Can't find CD-ROM

[Eris Discordia]

On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
<evas@mountaincable.net> wrote:

> As far as I know there is no Open dialog box in Plan9.

Not in Plan 9. I thought you might be getting the Virtual PC settings
wrong and was referring to the settings on the menu bar on top of your
virtual machine window (which belongs to VPC).

> I have several times brought the instalation up to
> this point and the installer suggests that the install image should be at
> /dev/sdD0/data.


If you have come this far, it is clear I was wrong. The install image is
indeed where the installer suggests, at /dev/sdD0/data.

I guess you get the problem later on when you are asked (by the Plan 9
installer) to "browse" for the distribution (at the copydist stage of the
installation). At that point, having supplied /dev/sdD0/data as your data
source before, you have to tell the installer to look in the / directory
of the image for the distribution to copy. Just type in "/" (without the
quotes) there.

I think it is acceptable to reiterate that: "Plan 9 does NOT work on VPC's
current version. Try QEMU instead." I have the latest version of VPC for
Windows XP x64 and no amount of usual tweaking would make Plan 9 work on
it. The installation finishes but the installed system will not boot past
the startup scripts. Yours will probably fail, too. My two cents of
failure :-)

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Can't find CD-ROM

[Chris Saunders]

Thanks, I have downloaded but not yet installed QEMU.  I will try this soon.

Regards
Chris Saunders

"Eris Discordia" <eris.discordia@gmail.com> wrote in message
news:op.t6c8ovxgc6yvfe@computer...
> On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
> <evas@mountaincable.net> wrote:
>
>> As far as I know there is no Open dialog box in Plan9.
>
> Not in Plan 9. I thought you might be getting the Virtual PC settings
> wrong and was referring to the settings on the menu bar on top of your
> virtual machine window (which belongs to VPC).
>
>> I have several times brought the instalation up to
>> this point and the installer suggests that the install image should be at
>> /dev/sdD0/data.
>
>
> If you have come this far, it is clear I was wrong. The install image is
> indeed where the installer suggests, at /dev/sdD0/data.
>
> I guess you get the problem later on when you are asked (by the Plan 9
> installer) to "browse" for the distribution (at the copydist stage of the
> installation). At that point, having supplied /dev/sdD0/data as your data
> source before, you have to tell the installer to look in the / directory
> of the image for the distribution to copy. Just type in "/" (without the
> quotes) there.
>
> I think it is acceptable to reiterate that: "Plan 9 does NOT work on VPC's
> current version. Try QEMU instead." I have the latest version of VPC for
> Windows XP x64 and no amount of usual tweaking would make Plan 9 work on
> it. The installation finishes but the installed system will not boot past
> the startup scripts. Yours will probably fail, too. My two cents of
> failure :-)
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Can't find CD-ROM

[Lee Duhem]

Take a look at Qemu Manager: http://www.davereyn.co.uk/about.htm

2008/2/12, Chris Saunders <evas@mountaincable.net>:
> Thanks, I have downloaded but not yet installed QEMU.  I will try this soon.
>
> Regards
> Chris Saunders
>
> "Eris Discordia" <eris.discordia@gmail.com> wrote in message
> news:op.t6c8ovxgc6yvfe@computer...
> > On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
> > <evas@mountaincable.net> wrote:
> >
> >> As far as I know there is no Open dialog box in Plan9.
> >
> > Not in Plan 9. I thought you might be getting the Virtual PC settings
> > wrong and was referring to the settings on the menu bar on top of your
> > virtual machine window (which belongs to VPC).
> >
> >> I have several times brought the instalation up to
> >> this point and the installer suggests that the install image should be at
> >> /dev/sdD0/data.
> >
> >
> > If you have come this far, it is clear I was wrong. The install image is
> > indeed where the installer suggests, at /dev/sdD0/data.
> >
> > I guess you get the problem later on when you are asked (by the Plan 9
> > installer) to "browse" for the distribution (at the copydist stage of the
> > installation). At that point, having supplied /dev/sdD0/data as your data
> > source before, you have to tell the installer to look in the / directory
> > of the image for the distribution to copy. Just type in "/" (without the
> > quotes) there.
> >
> > I think it is acceptable to reiterate that: "Plan 9 does NOT work on VPC's
> > current version. Try QEMU instead." I have the latest version of VPC for
> > Windows XP x64 and no amount of usual tweaking would make Plan 9 work on
> > it. The installation finishes but the installed system will not boot past
> > the startup scripts. Yours will probably fail, too. My two cents of
> > failure :-)
> >
> > --
> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>

Re: [9fans] Can't find CD-ROM

[Chris Saunders]

Tried    QEMU but it wouldn't run on my system.  I'm running Vista Ultimate
64-bit and perhaps QEMU doesn't run on a 64-bit system.

Regards
Chris Saunders

"Chris Saunders" <evas@mountaincable.net> wrote in message
news:a35e9$47b14ec4$480c90cf$9726@MOUNTAINCABLE.NET...
> Thanks, I have downloaded but not yet installed QEMU.  I will try this
> soon.
>
> Regards
> Chris Saunders
>
> "Eris Discordia" <eris.discordia@gmail.com> wrote in message
> news:op.t6c8ovxgc6yvfe@computer...
>> On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
>> <evas@mountaincable.net> wrote:
>>
>>> As far as I know there is no Open dialog box in Plan9.
>>
>> Not in Plan 9. I thought you might be getting the Virtual PC settings
>> wrong and was referring to the settings on the menu bar on top of your
>> virtual machine window (which belongs to VPC).
>>
>>> I have several times brought the instalation up to
>>> this point and the installer suggests that the install image should be
>>> at
>>> /dev/sdD0/data.
>>
>>
>> If you have come this far, it is clear I was wrong. The install image is
>> indeed where the installer suggests, at /dev/sdD0/data.
>>
>> I guess you get the problem later on when you are asked (by the Plan 9
>> installer) to "browse" for the distribution (at the copydist stage of the
>> installation). At that point, having supplied /dev/sdD0/data as your data
>> source before, you have to tell the installer to look in the / directory
>> of the image for the distribution to copy. Just type in "/" (without the
>> quotes) there.
>>
>> I think it is acceptable to reiterate that: "Plan 9 does NOT work on
>> VPC's current version. Try QEMU instead." I have the latest version of
>> VPC for Windows XP x64 and no amount of usual tweaking would make Plan 9
>> work on it. The installation finishes but the installed system will not
>> boot past the startup scripts. Yours will probably fail, too. My two
>> cents of failure :-)
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Can't find CD-ROM

[Eris Discordia]

On Wed, 13 Feb 2008 09:52:19 -0000, Chris Saunders
<evas@mountaincable.net> wrote:

> Tried    QEMU but it wouldn't run on my system.  I'm running Vista
> Ultimate
> 64-bit and perhaps QEMU doesn't run on a 64-bit system.
>

That should not be a problem, I guess. My platform is Windows XP x64
Edition, essentially Windows Server 2003 64-bit Edition, on a P4 with
EM64T (similar to AMD64). And the 32-bit QEMU binaries have posed no
problem. There have been problems "emulating" Vista on QEMU, but none
running QEMU on Vista.

Please note that setting up QEMU may take a little bit of effort. The
procedure I went through was like this:

1. Install the QEMU 32-bit binaries using this installer:
http://www.h6.dion.ne.jp/~kazuw/qemu-win/Qemu-0.9.0-install.exe, no need
to install KQEMU drivers as they will not work on 64-bit Windows.

2. QEMU adds itself to your PATH environment variable. To check this, run
cmd.exe and type "qemu" (without the quotes, of course). If all is OK,
QEMU will run and output a help message.

3. Create a directory to store all your Plan 9 tidbits, with a short name
preferably as you are going to type it quite a few times, "C:\Plan9" for
example. Make sure you have at least 1 GB of space on the partition you
have created the directory in. I will assume you keep both the Plan 9 ISO
image and your virtual hard disk image in that directory.

4. Run cmd.exe (the Command Shell) and navigate to the directory you just
created. There, create a virtual HD image like this: "qemu-img create -fmt
raw mydisk.img 3G" which tells QEMU to create a VHD image in raw format
with a size of 3 GBs (I tried larger numbers at first, but they would end
up in useless files for no apparent reason). Now you must have the file
"mydisk.img" in your current directory. Double check by doing "qemu-img
info -fmt raw mydisk.img" and reading the output carefully.

5. Type and execute this at your command line: "qemu -hda "mydisk.img"
-cdrom plan9.iso -L "c:\Program Files (x86)\Qemu\pc-bios" -boot d" which
will run QEMU with "mydisk.img" as your VHD and the Plan 9 ISO image
(plan9.iso) inserted in your virtual CD-ROM drive. It will boot from the
ISO image. I have assumed that your QEMU installation is in "C:\Program
Files (x86)\Qemu" in which exists the "pc-bios" directory containing the
BIOS image necessary for bootstrapping the QEMU virtual machine.

6. If no other problems emerge, you will get to the Plan 9 install/live
system and do as you already know. Installation may take up to an hour,
because QEMU's disk emulation is (for reasons I do not understand) very
slow. When Plan 9 installation is done and the installer tells you it is
safe to turn off your computer, press [ctrl]+[alt]+[2] to switch to QEMU's
virtual console and therein type "q" to stop its execution.

7. Now, you may run the installed system with this command line: "qemu
-hda "mydisk.img" -L "c:\Program Files (x86)\Qemu\pc-bios" -boot c" which
boots the VM from the Plan 9 installation on "mydisk.img" and hopefully
gives you a working system.

8. To ease the task of running your system, you may want to put the
command line in (7) in a batch file and run that instead. For information
on QEMU, read the pretaining documentation which tell you all the
important things in a very clear manner. Have two things in mind, however,
first not to "turn off" the VM without giving an fshalt command to Plan 9,
second that all the VM's settigns (barring the most fundamental ones) can
be controlled by pressing [ctrl]+[alt]+[2] and getting to QEMU's virtual
console, where you may type "help" to get some help (that was obvious,
nah?). Pressing [ctrl]+[alt]+[1] takes you back to your running system.

9. Good luck.

10. The commandments are ten.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Fwd: Re: [9fans] Can't find CD-ROM

[Eris Discordia]

On Wed, 13 Feb 2008 16:52:05 -0000, Eris Discordia
<eris.discordia@gmail.com> wrote:

> 4. Run cmd.exe (the Command Shell) and navigate to the directory you
> just created. There, create a virtual HD image like this: "qemu-img
> create -fmt raw mydisk.img 3G" which tells QEMU to create a VHD image in
> raw format with a size of 3 GBs (I tried larger numbers at first, but
> they would end up in useless files for no apparent reason). Now you must
> have the file "mydisk.img" in your current directory. Double check by
> doing "qemu-img info -fmt raw mydisk.img" and reading the output
> carefully.
>

I am sorry, made a mistake there. Replace all "-fmt" with "-f" no
additional "mt."

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Can't find CD-ROM

[ISHWAR RATTAN]

Switch to qemu!

-ishwar

On Mon, 11 Feb 2008, Chris Saunders wrote:

> I am attempting to install Plan9 on Virtual PC.  I boots fine but later when
> I attempt to find the CD-ROM I cannot.  Could anyone help?
>
> Regards
> Chris Saunders
>

Re: [9fans] Can't find CD-ROM

[Alf]

> I am attempting to install Plan9 on Virtual PC.  I boots fine but later when
> I attempt to find the CD-ROM I cannot.  Could anyone help?
>

did you look under your desk ?

Re: [9fans] 9pfuse adventure

[sqweek]

On Feb 9, 2008 4:25 AM, Russ Cox <rsc@swtch.com> wrote:
> > provide any facility to attach as a different user. So, I modified the
> > attach strategy to look for a USER environment variable before falling
> > back on getuser(). I've attached the diff, hopefully I got everything.
>
> The name in the attach is almost just a comment.
> What matters is the name used inside the authentication
> protocol.  (The name in the attach is really only there for
> non-authenticated connections.)  So these changes
> shouldn't be necessary.

 Hm, I guess u9fs is misbehaving then?

> This is the problem: you should never be prompted for a
> role=speakfor key.  You should be prompted for a role=client key.
> If that happened correctly then I think things would have just
> worked.  Try pre-loading a role=client key into factotum and
> see if that works better.

 I'm pretty sure I did have a role=client key in factotum in my
previous attempts, added by drawterm (I have a cpu/authserver on my
home network aswell, with the same user/pass/dom as my u9fs.key). I
reran the tests to be sure, the log is below. It turns out I only get
asked for a speakfor key when using my modified USER code, but it's
still the only way I've got a usable connection.
 I had a quick look at u9fs and it does appear to be checking against
the Tattach uname in p9anyattach(), but if that check was failing I
should be getting "authentication failed" not "unknown user".
 Um, but that was a pretty silly place to look anyway. There's only
one place "unknown user" is actually returned, and that is after
uname2user fails in rattach() (which was probably the original reason
for my USER hack).
 I suspect there is no good solution here since if you called
uname2user() on the auth username, every user would connect with the
same permissions (I assume everyone connecting needs an auth key
matching /etc/u9fs.key?). Maybe it would work with tighter coupling
with the auth server? I never fully grasped the reason behind
/etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to
use.

$ 9p read factotum/ctl
key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password?

$ rm `namespace`/wren
$ srv -a sqweek.dnsdojo.org wren
$ 9p ls wren/
9p: mount: unknown user
$ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
/opt/plan9/src/cmd/o.9p: mount: unknown user

$ rm `namespace`/wren
$ srv sqweek.dnsdojo.org wren
$ 9p ls wren/
9p: mount: unknown user
$ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
!adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org

-sqweek, thinking he should probably have set inferno up a long time ago

Re: [9fans] 9pfuse adventure

[John Soros]

[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]

Hi!
well, i have been having this error for quite a while with 9pfuse. on amd64 linux (archlinux), i couldn't even ls a mounted directory, now that i have a 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to do with the arch, though).
this is how i mount sources with p9p:
$ 9fs sources
$ 9 mount `namespace`/sources /tmp/sources
then ls in a directory in /tmp/sources works, but when i try to copy, attached is the output.
I'm open to testing whatever fixes you might suggest.
regs
John

On Wed, 13 Feb 2008 04:40:27 +0900
sqweek <sqweek@gmail.com> wrote:

> On Feb 9, 2008 4:25 AM, Russ Cox <rsc@swtch.com> wrote:
> > > provide any facility to attach as a different user. So, I modified the
> > > attach strategy to look for a USER environment variable before falling
> > > back on getuser(). I've attached the diff, hopefully I got everything.
> >
> > The name in the attach is almost just a comment.
> > What matters is the name used inside the authentication
> > protocol.  (The name in the attach is really only there for
> > non-authenticated connections.)  So these changes
> > shouldn't be necessary.
>
>  Hm, I guess u9fs is misbehaving then?
>
> > This is the problem: you should never be prompted for a
> > role=speakfor key.  You should be prompted for a role=client key.
> > If that happened correctly then I think things would have just
> > worked.  Try pre-loading a role=client key into factotum and
> > see if that works better.
>
>  I'm pretty sure I did have a role=client key in factotum in my
> previous attempts, added by drawterm (I have a cpu/authserver on my
> home network aswell, with the same user/pass/dom as my u9fs.key). I
> reran the tests to be sure, the log is below. It turns out I only get
> asked for a speakfor key when using my modified USER code, but it's
> still the only way I've got a usable connection.
>  I had a quick look at u9fs and it does appear to be checking against
> the Tattach uname in p9anyattach(), but if that check was failing I
> should be getting "authentication failed" not "unknown user".
>  Um, but that was a pretty silly place to look anyway. There's only
> one place "unknown user" is actually returned, and that is after
> uname2user fails in rattach() (which was probably the original reason
> for my USER hack).
>  I suspect there is no good solution here since if you called
> uname2user() on the auth username, every user would connect with the
> same permissions (I assume everyone connecting needs an auth key
> matching /etc/u9fs.key?). Maybe it would work with tighter coupling
> with the auth server? I never fully grasped the reason behind
> /etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to
> use.
>
> $ 9p read factotum/ctl
> key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password?
>
> $ rm `namespace`/wren
> $ srv -a sqweek.dnsdojo.org wren
> $ 9p ls wren/
> 9p: mount: unknown user
> $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
> /opt/plan9/src/cmd/o.9p: mount: unknown user
>
> $ rm `namespace`/wren
> $ srv sqweek.dnsdojo.org wren
> $ 9p ls wren/
> 9p: mount: unknown user
> $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
> !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org
>
> -sqweek, thinking he should probably have set inferno up a long time ago

[-- Attachment #2: cp.output --]
[-- Type: application/octet-stream, Size: 3913 bytes --]

$ cp -r sources/plan9/sys/src/cmd/unix/u9fs /home/johnny/dev/aur/tmp
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/LICENSE' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/authnone.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/authp9any.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/authrhosts.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/convD2M.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/convM2D.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/convM2S.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/convS2M.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/cygwin.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/des.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/dirmodeconv.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/doprint.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/fcall.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/fcallconv.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/makefile' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/oldfcall.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/oldfcall.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/plan9.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/print.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/random.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/readn.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/remotehost.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/rune.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/safecpy.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/strecpy.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/sun-inttypes.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/tokenize.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/u9fs.c' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/u9fs.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/u9fsauth.h' for reading: Permission denied
unexpected open flags 0500000cp: cannot open `sources/plan9/sys/src/cmd/unix/u9fs/utfrune.c' for reading: Permission denied
$

Re: [9fans] 9pfuse adventure

[sqweek]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

 Right. On 64-bit arches, linux forces the O_LARGEFILE (0x8000) flag
in sys_open(). FUSE passes the flags along in fuse_send_open(), which
makes its way to 9pfuse's _fuseopen(). _fuseopen() _tries_ to ignore
the O_LARGEFILE flag, but on 64-bit arches, the userspace fcntl header
<bits/fcntl.h> defines O_LARGEFILE as 0... even though the kernel
still treats it as 0x8000.
 Friggin mess. Patch attached.
-sqweek

On Fri, Mar 21, 2008 at 7:08 PM, John Soros <sorosj@gmail.com> wrote:
> Hi!
>  well, i have been having this error for quite a while with 9pfuse. on amd64 linux (archlinux), i couldn't even ls a mounted directory, now that i have a 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to do with the arch, though).
>  this is how i mount sources with p9p:
>  $ 9fs sources
>  $ 9 mount `namespace`/sources /tmp/sources
>  then ls in a directory in /tmp/sources works, but when i try to copy, attached is the output.
>  I'm open to testing whatever fixes you might suggest.
>  regs
>  John

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 9pfuse.LARGEFILE.diff --]
[-- Type: text/x-patch; name=9pfuse.LARGEFILE.diff, Size: 924 bytes --]

Index: main.c
===================================================================
RCS file: /cvs/plan9/src/cmd/9pfuse/main.c,v
retrieving revision 1.14
diff -u -r1.14 main.c
--- main.c	23 Nov 2007 21:28:33 -0000	1.14
+++ main.c	27 Mar 2008 02:47:39 -0000
@@ -24,11 +24,19 @@
 #endif
 
 #ifndef O_LARGEFILE
-#  if defined(__linux__)
-#    define O_LARGEFILE 0100000  /* Sigh */
-#  else
-#    define O_LARGEFILE 0
-#  endif
+#  define O_LARGEFILE 0
+#endif
+
+/* Work around glibc's broken <bits/fcntl.h> which defines
+ * O_LARGEFILE to 0 on 64 bit architectures.  But, on those same
+ * architectures, linux _forces_ O_LARGEFILE (which is always
+ * 0100000 in the kernel) at each file open. FUSE is all too
+ * happy to pass the flag onto us, where we'd have no idea what
+ * to do with it if we trusted glibc.
+ */
+#if defined(__linux__)
+#  undef O_LARGEFILE
+#  define O_LARGEFILE 0100000
 #endif
 
 #ifndef O_CLOEXEC