[9fans] ape/psh can't exec in 9vx

[9fans] ape/psh can't exec in 9vx

[Gary V. Vaughan]

Was just starting to settle in to 9vx, but this is a real showstopper:

   term% ls -ld /bin/ape
   d-rwxr-xr-x Z 1 gary gary 578 Sep 23 11:28 /bin/ape
   term%  ls -l /bin/ape/sh
   --rwxr-xr-x Z 1 gary gary 482209 Sep 23 11:28 /bin/ape/sh
   term% /bin/ape/uname -a
   Plan9 vx32 4 0 i386
   term% ape/psh
   $ /bin/ape/uname -a
   /bin/sh: /bin/ape/uname: cannot execute - Access denied

Any ideas on how to debug this one?

Cheers,
	Gary
--
Email me:          gary@gnu.org                          ._(()
Read my blog:      http://blog.azazil.net                 \' )
And my other blog: http://www.machaxor.net                =( \
...and my book:    http://sources.redhat.com/autobook     _(~_)'

Re: [9fans] ape/psh can't exec in 9vx

[andrey mirtchovski]

i couldn't find out what the bug was but it was in the library's
interaction with the VM environment and not in SH: for example, pcc
also crashed when attempting to exec ape's 'diff'. acid's truss wasn't
useful since it immediately faulted with: "invalid opcode 8c 24 d0 at
eip 000130c3"

anyway, if you just recompile "ape" you will not see the problem, or
at least that's what worked for me:

% cd /sys/src/ape
% mk nuke && mk install
% uname
uname: '/bin/uname' file does not exist
% ape/psh
$ uname -a
Plan9 vx32 4 0 i386
$

you may want to do it from the init rc window before you have started
rio: it crashed the VM with "9vx panic: sigsegv on cpu3" with amazing
regularity.

andrey
On Tue, Sep 23, 2008 at 11:17 PM, Gary V. Vaughan <gary@gnu.org> wrote:
> Was just starting to settle in to 9vx, but this is a real showstopper:
>
>  term% ls -ld /bin/ape
>  d-rwxr-xr-x Z 1 gary gary 578 Sep 23 11:28 /bin/ape
>  term%  ls -l /bin/ape/sh
>  --rwxr-xr-x Z 1 gary gary 482209 Sep 23 11:28 /bin/ape/sh
>  term% /bin/ape/uname -a
>  Plan9 vx32 4 0 i386
>  term% ape/psh
>  $ /bin/ape/uname -a
>  /bin/sh: /bin/ape/uname: cannot execute - Access denied
>
> Any ideas on how to debug this one?
>
> Cheers,
>        Gary
> --
> Email me:          gary@gnu.org                          ._(()
> Read my blog:      http://blog.azazil.net                 \' )
> And my other blog: http://www.machaxor.net                =( \
> ...and my book:    http://sources.redhat.com/autobook     _(~_)'
>
>
>

Re: [9fans] ape/psh can't exec in 9vx

[Gary V. Vaughan]

Hi Andrey,

On 24 Sep 2008, at 13:52, andrey mirtchovski wrote:
> On Tue, Sep 23, 2008 at 11:17 PM, Gary V. Vaughan <gary@gnu.org>
> wrote:
>> Was just starting to settle in to 9vx, but this is a real
>> showstopper:
>>
>> term% ls -ld /bin/ape
>> d-rwxr-xr-x Z 1 gary gary 578 Sep 23 11:28 /bin/ape
>> term%  ls -l /bin/ape/sh
>> --rwxr-xr-x Z 1 gary gary 482209 Sep 23 11:28 /bin/ape/sh
>> term% /bin/ape/uname -a
>> Plan9 vx32 4 0 i386
>> term% ape/psh
>> $ /bin/ape/uname -a
>> /bin/sh: /bin/ape/uname: cannot execute - Access denied
>>
>> Any ideas on how to debug this one?
>
> i couldn't find out what the bug was but it was in the library's
> interaction with the VM environment and not in SH: for example, pcc
> also crashed when attempting to exec ape's 'diff'. acid's truss wasn't
> useful since it immediately faulted with: "invalid opcode 8c 24 d0 at
> eip 000130c3"

Hmmm... so the real problem is with the binaries in the dist tarball?

Which implies that compiling binaries for 9vx.OSX in a regular plan 9
environment is doing something bad.

> anyway, if you just recompile "ape" you will not see the problem, or
> at least that's what worked for me:
>
> % cd /sys/src/ape
> % mk nuke && mk install
> % uname
> uname: '/bin/uname' file does not exist
> % ape/psh
> $ uname -a
> Plan9 vx32 4 0 i386
> $

Yep, works like a charm!  Many thanks again :)

> you may want to do it from the init rc window before you have started
> rio: it crashed the VM with "9vx panic: sigsegv on cpu3" with amazing
> regularity.

I threw caution to the wind and ran the rebuild inside rio, and didn't
have anything unusual happen.  I'll keep an eye out for those panics
though, incase I find a way to get them repeatably.

Does that mean I can also recompile replica in 9vx and have it work
correctly?  Or does ape have special issues of its own that require
a rebuild in the host environment?

Cheers,
	Gary
--
Email me:          gary@gnu.org                          ._(()
Read my blog:      http://blog.azazil.net                 \' )
And my other blog: http://www.machaxor.net                =( \
...and my book:    http://sources.redhat.com/autobook     _(~_)'

Re: [9fans] ape/psh can't exec in 9vx

[andrey mirtchovski]

> I threw caution to the wind and ran the rebuild inside rio, and didn't
> have anything unusual happen.  I'll keep an eye out for those panics
> though, incase I find a way to get them repeatably.

I was serving the 9vx window from a fairly remote Linux box, that may
have contributed.

> Does that mean I can also recompile replica in 9vx and have it work
> correctly?  Or does ape have special issues of its own that require
> a rebuild in the host environment?
>

unfortunately I don't know. i wish i had more chance to figure out
what was causing the original problem.

Re: [9fans] ape/psh can't exec in 9vx

[Steve Simon]

I may be wrong but I assumed the problem with replica was that unless you run 9vx
setuid to root and trust the permssion checking in the host interface there is
no way for wstat to change the username of a file to anything else that the user
who started 9vx.

aditionally there may b e no relevant host user to become the owner of the file,
e.g. bootes or glenda.

If it is just limitations of the host filesystem emulating a 9p server then replica
should work fine when it uses a seperate fossil disk partition rather than a host
filesystem.

If I am right you could always add a file which contains extra metadata not stored
in the host filesystem (e.g. the append bit, the 't' bit (don't venti) and of
course owner and group - overriding the owner and group from the native filesystem.

wether this is worth the effort... thats another question.

alternatively the 9vx host filesystem interface or replica itself could be hacked to
be less strict when wstats()ing.

then again I may have the wrong end of the stick completely.

-Steve

Re: [9fans] ape/psh can't exec in 9vx

[roger peppe]

last time i looked, wstat was largely unimplemented on the host
filesystem interface, but that was a while ago, so it's probably changed.

it caused the inferno build to fail.

Re: [9fans] ape/psh can't exec in 9vx

[Uriel]

Or we could use extended attributes to store the plan9-related bits.

I'm joking, I'm joking! I just couldn't resist mentioning such wicked idea ;))

Probably having fossil become part of the default setup would be the best.

Peace

uriel


On Wed, Sep 24, 2008 at 5:56 PM, Steve Simon <steve@quintile.net> wrote:
> I may be wrong but I assumed the problem with replica was that unless you run 9vx
> setuid to root and trust the permssion checking in the host interface there is
> no way for wstat to change the username of a file to anything else that the user
> who started 9vx.
>
> aditionally there may b e no relevant host user to become the owner of the file,
> e.g. bootes or glenda.
>
> If it is just limitations of the host filesystem emulating a 9p server then replica
> should work fine when it uses a seperate fossil disk partition rather than a host
> filesystem.
>
> If I am right you could always add a file which contains extra metadata not stored
> in the host filesystem (e.g. the append bit, the 't' bit (don't venti) and of
> course owner and group - overriding the owner and group from the native filesystem.
>
> wether this is worth the effort... thats another question.
>
> alternatively the 9vx host filesystem interface or replica itself could be hacked to
> be less strict when wstats()ing.
>
> then again I may have the wrong end of the stick completely.
>
> -Steve

Re: [9fans] ape/psh can't exec in 9vx

[Uriel]

Which makes me wonder, doesn't Inferno have to deal with the same
issue? It has never been quite clear to me how it does it, the whole
inferno<->host user mapping stuff has always confused me.

Peace

uriel

On Wed, Sep 24, 2008 at 6:09 PM, roger peppe <rogpeppe@gmail.com> wrote:
> last time i looked, wstat was largely unimplemented on the host
> filesystem interface, but that was a while ago, so it's probably changed.
>
> it caused the inferno build to fail.
>
>

Re: [9fans] ape/psh can't exec in 9vx

[Dmitry Golubovsky]

> On Oct 19, 11:50 am, r...@swtch.com (Russ Cox) wrote:
>
> > > /bin/sh: uname: cannot execute - Access denied
>
> > I believe that if you build a new binary from the sources
> > instead of using the pre-compiled binary, this bug is fixed.
> > The binaries are lagging behind the actual source code.
>

Yes, doing the both things have helped.

Re: [9fans] ape/psh can't exec in 9vx

[Dmitry Golubovsky]

On Oct 19, 11:50 am, r...@swtch.com (Russ Cox) wrote:
> > /bin/sh: uname: cannot execute - Access denied
>
> I believe that if you build a new binary from the sources
> instead of using the pre-compiled binary, this bug is fixed.
> The binaries are lagging behind the actual source code.
>
> Russ

OK, I'll try both this and what Andrey recommended.

Thanks.

Re: [9fans] ape/psh can't exec in 9vx

[Russ Cox]

> /bin/sh: uname: cannot execute - Access denied

I believe that if you build a new binary from the sources
instead of using the pre-compiled binary, this bug is fixed.
The binaries are lagging behind the actual source code.

Russ

[9fans] ape/psh can't exec in 9vx

[Dimitry Golubovsky]

Hi,

Sorry if this is a dup, I have tried to post via Google Groups, but
the message did not show up.

This was discussed about a year ago. I ran into the same problem. I
followed the advice to recompile ape. Recompilation was without errors
or crashes, but gave no effect: I still see the same

$ uname
/bin/sh: uname: cannot execute - Access denied

from the ape shell.

I use a Plan9 iso image http://www.kix.in/plan9/plan9.iso.bz2 as a
root fiesystem for 9vx (I extracted all files from it and made them
writable).

What I am running:

9vx.Linux 0.12 from the pre-built snapshot

on top of

[dima@archgui 9vx-0.12-iso]$ uname -a
Linux archgui 2.6.27-ARCH #1 SMP PREEMPT Sun Dec 21 09:31:10 UTC 2008
i686 QEMU Virtual CPU version 0.9.1 AuthenticAMD GNU/Linux

(that is, a KVM guest)

and the physical host for KVM is

dima@www:~$ uname -a
Linux www 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux

(Ubuntu Intrepid)

Has anybody encountered the same problem recently? I saw no posts on
this mailing list on the topic since the original discussion.

Or, is there any other known image of Plan9 root filesystem which does
not have the same problem with 9vx?

Thanks for any ideas.

--
Dimitry Golubovsky

Anywhere on the Web