[9fans] 9pfuse adventure - Plan9

This is a discussion on [9fans] 9pfuse adventure - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: [9fans] 9pfuse adventure

  1. [9fans] 9pfuse adventure

    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
    -> 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)

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

    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


    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
    -> 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=) 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/T...day/index.html
    [2] http://lists.cse.psu.edu/archives/9f...er/056900.html


  2. Re: [9fans] 9pfuse adventure

    > 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


  3. Can't find CD-ROM

    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

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

    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



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

    On Mon, 11 Feb 2008 09:31:15 -0000, 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


    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/

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

    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
    >


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

    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" 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


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

    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.


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

    On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
    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/

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


    > 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 ?

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

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

    Regards
    Chris Saunders

    "Eris Discordia" wrote in message
    newsp.t6c8ovxgc6yvfe@computer...
    > On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
    > 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/



  12. Re: [9fans] 9pfuse adventure

    On Feb 9, 2008 4:25 AM, Russ Cox 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

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

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

    2008/2/12, Chris Saunders :
    > Thanks, I have downloaded but not yet installed QEMU. I will try this soon.
    >
    > Regards
    > Chris Saunders
    >
    > "Eris Discordia" wrote in message
    > newsp.t6c8ovxgc6yvfe@computer...
    > > On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
    > > 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/

    >
    >


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

    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" wrote in message
    news:a35e9$47b14ec4$480c90cf$9726@MOUNTAINCABLE.NE T...
    > Thanks, I have downloaded but not yet installed QEMU. I will try this
    > soon.
    >
    > Regards
    > Chris Saunders
    >
    > "Eris Discordia" wrote in message
    > newsp.t6c8ovxgc6yvfe@computer...
    >> On Mon, 11 Feb 2008 14:54:20 -0000, Chris Saunders
    >> 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/


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

    On Wed, 13 Feb 2008 09:52:19 -0000, Chris Saunders
    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....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/

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

    On Wed, 13 Feb 2008 16:52:05 -0000, Eris Discordia
    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/

  17. Re: [9fans] 9pfuse adventure

    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 wrote:

    > On Feb 9, 2008 4:25 AM, Russ Cox 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



+ Reply to Thread