Hi,
vmware esx only supports scsi virtual drives.
Which version of ESX are you using? ESX 3.5 provides two types of
SCSI controllers.
One is BusLogic and the other is LSI Logic which is the default. If
you change the
controller type to BusLogic, Plan 9 should install on ESX without problems.
2009/10/2 Sam Watkins s...@nipl.net:
could be removed if anyone fixes hg.
from the way the mercurial guys go on about it,
it sounds like the fix might not be trivial.
it does seem like a ridiculous thing, but it
seems to be something of a religious issue with them.
hg doesn't do permissions
it does seem like a ridiculous thing, but it
seems to be something of a religious issue with them.
that was my impression. we aren't the only ones to find
the restriction irksome, by any means. to avoid this
intransigence spreading, i should say that we'll compensate
for it somehow. i agree with
Hello,
I would like to know if the fellow below (Andreas Erikson), ever tried
to compile plan 9 xen3 sources against xen 3.2.x (or 3.[2-4].x for that
matter). I am going to try that this weekend, and if he started to
patch some code, I would appreciate the head start.
From: Richard
Plan 9 does not work with either of the SCSI controllers in ESX(i) 3.5
or less. Plan 9 does run on IDE drives just fine in ESX(i) 4. Plan 9
panicks if you give it more than 2 CPUs on any of them. If you have
any questions about getting Plan 9 to run in ESX(i) 4, let me know;
I've done it. But you
I tried, but it was beyond my limited time and understanding. I hope
you succeed. I am using Xen (specifically, Citrix XenServer) in a
project I am working on now, and would very much like to run Plan 9 as
a part of that.
Good luck!
–Andreas
On 2. Oct, 2009, at 3:21 PM, Jack Norton
On Fri, Oct 2, 2009 at 1:44 AM, roger peppe rogpe...@gmail.com wrote:
2009/10/2 Sam Watkins s...@nipl.net:
could be removed if anyone fixes hg.
from the way the mercurial guys go on about it,
it sounds like the fix might not be trivial.
it does seem like a ridiculous thing, but it
seems
I have a dell inspiron 700m. I can boot the install cd just fine and
everything seems to work out of the box. I select a fossil
fileserver.
When I get to the partdisk task, it shows my harddrive as sdC0. I
select
that and I get
fdisk 1040: suicide:sys:trap: divide error pc=0x00825d4
sdc0 is
sdc0 is reported as a Toshiba MK4026GAX, its a 40gb harddrive. I have
tried it with out dma and with, no difference. I have tried manually
running it
and have had the same result. The number (1040) after fdisk changes,
is that
number of the command in rc? i.e. the 1040th command run, but the
Which version of ESX are you using? ESX 3.5 provides two types of
SCSI controllers.
One is BusLogic and the other is LSI Logic which is the default. If
you change the
controller type to BusLogic, Plan 9 should install on ESX without problems.
yes, switching to BusLogic did the trick.
Plan 9 does not work with either of the SCSI controllers in ESX(i) 3.5
or less. Plan 9 does run on IDE drives just fine in ESX(i) 4. Plan 9
panicks if you give it more than 2 CPUs on any of them. If you have
any questions about getting Plan 9 to run in ESX(i) 4, let me know;
I've done it. But
Somehow my laptop gets by using 32-bit IP addresses regardless of
whether it's on my home Ethernet, a dialup connection (rare these
days in the U.S., still sometimes useful overseas), or on a
wireless LAN.
My landline phone and my cellular phone both use base-10 digits,
and even the same
Instrumented each return from convM2S.c.
j...@jdc-desktop:/n/sources/contrib/catenate/times$ sudo cp
/home/jdc/contrib/latin1.7a.font .
ap(9cd1a0) + size(b) == p(9cd1ab)
ap(9d0510) + size(52) == p(9d0562)
ap(9d04e0) + size(21) == p(9d0501)
ap(9d02a0) + size(16) == p(9d02b6)
ap(9d02a0) + size(b)
It's a bit sad when a modern OS (inferno) from one of the best labs in the
world does not build (from hg), due to a error that could be avoided with a
tiny patch. You are losing new users because of this (or aggrevating them).
Why not commit the list of empty directories and add mkdir -p
committing a .emptydir file in each directory would be easier.
why bother making it .emptydir (ie, with the dot) when that makes it
invisible on broken host systems (with the ls bug) but visible under inferno
itself.
more important, and the reason i didn't do that,
if it's visible under inferno
On Oct 2, 2009, at 1:31 PM, Charles Forsyth wrote:
committing a .emptydir file in each directory would be easier.
why bother making it .emptydir (ie, with the dot) when that makes it
invisible on broken host systems (with the ls bug) but visible under
inferno itself.
more important, and
Hi
in man 9p
In general, the File interface is appropriate for maintaining
arbitrary file trees (as in ramfs). The File interface is best avoided
when the tree structure is easily generated as necessary; this is true
when the tree is highly structured (as in cdfs and nntpfs) or is
maintained
Perhaps a rule in the mkfile which would check/create empty directories?
perhaps. there are several alternatives, and no doubt i'll switch
to use a mix as appropriate. the annoying thing is that
previously, whether through tar, replica, or even subversion, a suitable
skeleton would appear without
On Fri, Oct 2, 2009 at 8:21 AM, Jack Norton j...@0x6a.com wrote:
I would like to know if the fellow below (Andreas Erikson), ever tried to
compile plan 9 xen3 sources against xen 3.2.x (or 3.[2-4].x for that
matter). I am going to try that this weekend, and if he started to patch
some code,
In general, the File interface is appropriate for maintaining
arbitrary file trees (as in ramfs). The File interface is best avoided
when the tree structure is easily generated as necessary; this is true
when the tree is highly structured (as in cdfs and nntpfs) or is
maintained elsewhere.
20 matches
Mail list logo
