On Fri, 21 Aug 2009 21:34:03 EDT Akshat Kumar
wrote:
> If I start QEMU with the option to boot directly from
> the HD image, as opposed to booting from network,
> then it starts up fine - but then the kernel is different
> also. I don't know what part of this is really troublesome.
> Maybe the p
On Fri Aug 21 21:35:38 EDT 2009, aku...@mail.nanosouffle.net wrote:
> > i also see it trying to auth bootes (i think).
> > do you have a user bootes?
>
> Yes, bootes is the hostowner of the CPU/Auth
> server.
also must have a user bootes on the fs even with
auth disabled.
might be good to turn o
> i also see it trying to auth bootes (i think).
> do you have a user bootes?
Yes, bootes is the hostowner of the CPU/Auth
server.
I've got a QEMU image that was distributed by
Devon, so I could at least try to get into Plan 9
inside QEMU and try to connect to Ken FS
server from there. I'm still
On Fri, Aug 21, 2009 at 6:28 PM, Akshat
Kumar wrote:
> This time with just
> flag authdebug
> and without going through secstore, since
> it gave me the problem highlighted above,
> plain auth from the QEMU host gives the
> following at Ken FS:
>
> il: allocating ...
> user akumar = 2 authenticated
This time with just
flag authdebug
and without going through secstore, since
it gave me the problem highlighted above,
plain auth from the QEMU host gives the
following at Ken FS:
il: allocating ...
user akumar = 2 authenticated
authorize: uid is 2
authorize: uid is 2
hangup! connection timed out-
Thank you for your input, Erik.
I haven't yet gotten to replacing
Ken FS proper with your version,
though I soon hope to do so (I'd
need to figure out how to boot it,
as your version has problems with
floppies - and I can only floppy
boot). Preferably in a fashion that
I can keep my current data. Y
> il: allocating il!192.168.1.20!50738
> hangup! connection timed out-3 50738/192.168.1.20.17008
>
> where 192.168.1.20 is the IP of the Plan 9
> instance inside QEMU.
>
> So, at least a connection is initially being
> made... I don't know why it would time out.
my best guess is an authenticatio
And here's another piece to the puzzle
that I just noticed: on the Ken FS server,
I see the following:
il: allocating il!192.168.1.20!50738
hangup! connection timed out-3 50738/192.168.1.20.17008
where 192.168.1.20 is the IP of the Plan 9
instance inside QEMU.
So, at least a connection is initia
> So, could it be that there are problems
> doing IL through QEMU? There shouldn't
> be, as the pcap device sends directly
> through the interface... so far as I can
> tell.
>
> Input welcome.
do a packet trace from the host.
it's also possible to turn on some
il tracing on the fs. here are a co
Upon Steve's suggestion, I enabled
*nodumpstack=1 in the PXE config
for the Plan 9 in QEMU. The result
follows:
...
password:
!
time...
panic: boot process died: sys: demand load I/O error accessing
/386/init: mount rpc error
panic: boot process died: sys: demand load I/O error accessing
/386/init
you can configure Qemu to use the host console as the guest serial console
11 matches
Mail list logo
