Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-08 Thread Jack Norton

Stanley Lieber wrote:

I'm installed.

-sl



Great to hear!

Last night I successfully set up a cpu/auth in the vps and even fired up 
httpd and started serving http (and I could drawterm to it without 
issue).  I didn't have an ip issue (however I did chase my tail due to a 
misconfigured /cfg/.../cpurc).

However..
I broke something bad.  Well, I don't think *I* did it but something is 
wrong.  I can no longer boot my VPS at all.  As in, the VNC is refusing 
connections (which means the VPS doesn't even begin to boot -- which 
means it isn't my fault... probably).  I have no confirmation that the 
VPS is running at all as the management console isn't connecting either...

So I don't know what happened but hopefully they can work it out.

I was just about to try to boot without *norealmode=1 now that the 8139 
NIC was in place.  I'd like to boot this thing without all those 
workarounds (though it runs great -- well ran great...).


All in all, I think they've got a working setup for Plan 9 hosting.  So 
my current troubles aside, this is big news.


-Jack



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-08 Thread Stanley Lieber
 I broke something bad.  Well, I don't think *I* did it but something is 
 wrong.  I can no longer boot my VPS at all.  As in, the VNC is refusing 
 connections (which means the VPS doesn't even begin to boot -- which 
 means it isn't my fault... probably).  I have no confirmation that the 
 VPS is running at all as the management console isn't connecting either...
 So I don't know what happened but hopefully they can work it out.

Ouch. Usually, failure to connect via VNC indicates the VPS may be powered
down. However, I don't think I've ever been locked out of the management
console.


 I was just about to try to boot without *norealmode=1 now that the 8139 
 NIC was in place.  I'd like to boot this thing without all those 
 workarounds (though it runs great -- well ran great...).

Our setups may not be precisely identical, but when I tried booting with
that NIC, without *noe820scan or *norealmode, I got the same freeze-ups
as before.


 All in all, I think they've got a working setup for Plan 9 hosting.  So 
 my current troubles aside, this is big news.

I'm certainly happy. Thanks for contributing you ideas and experiences.
I was very much stuck.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread Jack Norton

Stanley Lieber wrote:

On Sun Mar  6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote:

9atom's 9load prints %d e820 entries on boot.  is that number 0?

found 7 e8s0 entries

Then it freezes.

it's not the e820 code, then.  it's either falling over initializing the
console, or it's falling over probing devices for the .ini file.

after e820, 9load starts up the console and probes devices looking
for a .ini file.

i would think the odds are good that 9load has found an i/o port
that should not be touched.  devices are probed in this order
floppy. ether, cd, sd.

i don't really have a kvm setup, but if it's possible, you might try
removing devices (espeically ethernet devices) from a copy of 9load
until you find something that boots, then add 'em back in till it doesn't.

sounds tedious, no?  :-)


I'm perfectly willing. Two main problems at this point:

- I don't have immediate access to amd64 hardware to setup my own KVM/qemu.
I learned the hard way that KVM inside another qemu or VMware guest doesn't
work.
- Changing out the CD-ROM image on the hosted VPS requires sending an e-mail
to technical support and waiting up to 24 hours for a response. I've been told
allowing users to dynamically change CD-ROM images is not an option.

Jack:

If you reading this, do you want to try this with your cron-swapped floppy 
images?

-sl


I would be willing, definitely.  However, I am committed to finishing 
the setup of a cpu/auth server in the VPS right now (I've got it 
installed, just need to find time to make the migration from terminal to 
cpu/auth -- probably lunch break today).  I want to reach the milestone 
of serving a page over http (which is the primary purpose of this VPS in 
the first place).
Once that is done, I can bring it down and start playing around with 
9loads and kernels loaded on my floppy image.


Also, see about setting up the floppy cron job on your vps.  If 
anything, having a floppy there makes things so much easier to quickly 
play with a new kernel.  No need to master a new install cd and have 
them waste all that bandwidth.


Also, I noticed that the probing plan9.ini step in the loader looks at 
the floppy first even if booting off the hd.  Since I couldn't remove 
the floppy all together, I have my install's plan9.ini merged into the 
plan9.ini of the floppy.
Just a minor annoyance I had no idea existed :).  Although it is a great 
little feature to rescue the system if I bork my plan9.ini...


Also, I really need to thank fgb as he gave me a little tip on irc about 
his modified 9load that allows you to pass new plan9.ini variables at 
boot.  I got disconnected before I could acknowledge.  I haven't tried 
it yet, but it could be useful.


-Jack




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread erik quanstrom
 Also, I really need to thank fgb as he gave me a little tip on irc about 
 his modified 9load that allows you to pass new plan9.ini variables at 
 boot.  I got disconnected before I could acknowledge.  I haven't tried 
 it yet, but it could be useful.

not quite sure what you mean by this, but 9load-e820
allows a var=val at any prompt.

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread Stanley Lieber
 Also, I really need to thank fgb as he gave me a little tip on irc about
 his modified 9load that allows you to pass new plan9.ini variables at
 boot.  I got disconnected before I could acknowledge.  I haven't tried
 it yet, but it could be useful.

 not quite sure what you mean by this, but 9load-e820
 allows a var=val at any prompt.

This is standard on 9atom.iso?

I can't access my VPS from here at work but I'll give it a try tonight.

-sl



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread erik quanstrom
On Mon Mar  7 12:06:34 EST 2011, stanley.lie...@gmail.com wrote:
  Also, I really need to thank fgb as he gave me a little tip on irc about
  his modified 9load that allows you to pass new plan9.ini variables at
  boot.  I got disconnected before I could acknowledge.  I haven't tried
  it yet, but it could be useful.
 
  not quite sure what you mean by this, but 9load-e820
  allows a var=val at any prompt.
 
 This is standard on 9atom.iso?
 
 I can't access my VPS from here at work but I'll give it a try tonight.

yup.

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread Federico G. Benavento
years ago I needed to set some variables at boot time so I could get
Plan 9 running.

http://9fans.net/archive/2005/12/70

On Mon, Mar 7, 2011 at 1:24 PM, erik quanstrom quans...@labs.coraid.com wrote:
 Also, I really need to thank fgb as he gave me a little tip on irc about
 his modified 9load that allows you to pass new plan9.ini variables at
 boot.  I got disconnected before I could acknowledge.  I haven't tried
 it yet, but it could be useful.

 not quite sure what you mean by this, but 9load-e820
 allows a var=val at any prompt.

 - erik





-- 
Federico G. Benavento



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-07 Thread Stanley Lieber
I'm installed.

Made a custom boot floppy with the plan9.ini from plan9.iso's
boot.img. In addition,
one of either *noe820scan=1 or *norealmode=1 were required to avoid
the freeze-up
mentioned throughout this thread. The floppy's boot menu points to
kernels on the
plan9.iso that is configured as the IDE secondary master.

Taking another cue from Jack's experiences, I asked for the NIC to be
configured as
a RTL8139. With either option (*noe820scan or *norealmode), my installed system
can't pass icmp or tcp traffic to hosts on the local network.
Networking is configured
as normal (in fact, the configuration is identical to the Plan9 in
qemu I had working on
this same hardware under KVM/qemu - OpenBSD - kqemu/qemu - Plan 9). After
booting, the contents of /net/iproute, ip/ndb, etc., seem correct and
are consistent with
my other, working, Plan 9 systems.

The new system can ping it's own IP address, but cannot be pinged from
the local network.

I suspect there may be some sort of arp confusion in the ethernet
switch. This system
was previously configured with the same IP address, bridged from
kqemu/qemu to the
kqemu/qemu host's external interface (which itself was a virtual
interface hosted on
KVM/qemu). With this new configuration, the MAC address has changed.
I've submitted
a support request to check it out.

-sl



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread erik quanstrom
 Hello,
 
 I'm one of the other people trying to get plan 9 on the same VPS host 
 provider.  I've gotten past that hang.  Some haphazard print statements 
 narrowed the hang down to the e820 init function in memory.c.  So to 
 work around, setting either *noe820scan=1 or *norealmode=1 in plan9.ini 
 will allow you to boot in that VPS without the aforementioned hang.
 What the actual problem is, I don't know.  I'm fast approaching the end 
 of my abilities, so you'll have to pick it up from there.
 I'll know tomorrow how my install goes.
 I do know where exactly it does hang, but it's my bedtime.  I'll have to 
 drawterm into my cpu server and check my notes again to post where 
 exactly the boot hung.

have you tried the 9load from 9atom?  i moved the e820 scan
to before 9load switches from real mode, which should be
safer.  ftp://ftp.quanstro.net/other/^(9pxeload 9load)

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread Jack

On 3/6/2011 8:09 AM, erik quanstrom wrote:

Hello,

I'm one of the other people trying to get plan 9 on the same VPS host
provider.  I've gotten past that hang.  Some haphazard print statements
narrowed the hang down to the e820 init function in memory.c.  So to
work around, setting either *noe820scan=1 or *norealmode=1 in plan9.ini
will allow you to boot in that VPS without the aforementioned hang.
What the actual problem is, I don't know.  I'm fast approaching the end
of my abilities, so you'll have to pick it up from there.
I'll know tomorrow how my install goes.
I do know where exactly it does hang, but it's my bedtime.  I'll have to
drawterm into my cpu server and check my notes again to post where
exactly the boot hung.
 

have you tried the 9load from 9atom?  i moved the e820 scan
to before 9load switches from real mode, which should be
safer.  ftp://ftp.quanstro.net/other/^(9pxeload 9load)

- erik

   
I hadn't tried it.  I was under the impression that 9atom was tried by 
the OP of this thread.  My plan today is to go through with the install 
and see what happens.  I'll try your 9load next to see if I can boot 
sans excess options.
The support guy set up a cron job to update the floppy image from me, so 
I can try lots of different stuff (provided it fits in 1.44MB).


Thanks,
Jack



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread erik quanstrom
 I hadn't tried it.  I was under the impression that 9atom was tried by 
 the OP of this thread.  My plan today is to go through with the install 
 and see what happens.  I'll try your 9load next to see if I can boot 
 sans excess options.
 The support guy set up a cron job to update the floppy image from me, so 
 I can try lots of different stuff (provided it fits in 1.44MB).

you'll need the 9atom kernel as well.  (or to steal bits from
memory.c.)  i'd forgotten about that.  the dance is that 9load
stashes the e820 information in real mode and after it jumps
to protected mode, formats a config variable with the memory layout.
the kernel then recognizes this config variable and uses
it rather than calling bios.  the format of the variable is
[start end )*, so for example

minooka; whatis e820
e820='0 9c400 10 cfedeff0 1 13000 '

this machine has 3325mb starting at 1mb, and 768mb
of memory we waste starting at 4gb.

since we can override anything 9load makes up, it's
possible to tell the kernel this has any amout of memory
we wish by adding a like like the following to the plan9.ini

e820=0 9c400 10 cf00

obviously, telling the kernel it has memory that it doesn't
will be fatal, but you get the point.  :-)

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread Stanley Lieber
 have you tried the 9load from 9atom?  i moved the e820 scan
 to before 9load switches from real mode, which should be
 safer.  ftp://ftp.quanstro.net/other/^(9pxeload 9load)

 - erik


 I hadn't tried it.  I was under the impression that 9atom was tried by 
 the OP of this thread.  My plan today is to go through with the install 
 and see what happens.  I'll try your 9load next to see if I can boot 
 sans excess options.

I did indeed ask them to configure 9atom.iso as the CD-ROM and got
the same results as with plan9.iso. I trusted that the image was switched
but I'm not sure how I could verify.


 The support guy set up a cron job to update the floppy image from me, so 
 I can try lots of different stuff (provided it fits in 1.44MB).

Nice, I didn't know they'd let us do something like this.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread erik quanstrom
 I did indeed ask them to configure 9atom.iso as the CD-ROM and got
 the same results as with plan9.iso. I trusted that the image was switched
 but I'm not sure how I could verify.

i wasn't assuming that the two setups were identical.  let me
know if that's a bad assumption.

if 9atom fails during the realmode call to e820 in the kernel,
that would mean that there is no e820 map available at all.
i would think that means that the vm is assuming that we know
all the acpi tricks, and i'd find that very odd since afaik, linux
uses e820, even when acpi is available.  probablly because acpi
is too complicated to run before you know if you've got more
than ~480k to touch.

9atom's 9load prints %d e820 entries on boot.  is that number 0?

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread Stanley Lieber
 I did indeed ask them to configure 9atom.iso as the CD-ROM and got
 the same results as with plan9.iso. I trusted that the image was switched
 but I'm not sure how I could verify.
 
 i wasn't assuming that the two setups were identical.  let me
 know if that's a bad assumption.

We're customers of the same hosting company. As far as I know, the
KVM/qemu setup is identical save for possible differences in the amount
of RAM or hard disk space allotted for our respecitve service plans.


 9atom's 9load prints %d e820 entries on boot.  is that number 0?

I've submitted a request to have my VPS reconfigured with 9atom.iso.
We'll see!

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread Stanley Lieber
 9atom's 9load prints %d e820 entries on boot.  is that number 0?

found 7 e8s0 entries

Then it freezes.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread erik quanstrom
On Sun Mar  6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote:
  9atom's 9load prints %d e820 entries on boot.  is that number 0?
 
 found 7 e8s0 entries
 
 Then it freezes.

it's not the e820 code, then.  it's either falling over initializing the
console, or it's falling over probing devices for the .ini file.

after e820, 9load starts up the console and probes devices looking
for a .ini file.

i would think the odds are good that 9load has found an i/o port
that should not be touched.  devices are probed in this order
floppy. ether, cd, sd.

i don't really have a kvm setup, but if it's possible, you might try
removing devices (espeically ethernet devices) from a copy of 9load
until you find something that boots, then add 'em back in till it doesn't.

sounds tedious, no?  :-)

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-06 Thread Stanley Lieber
 On Sun Mar  6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote:
  9atom's 9load prints %d e820 entries on boot.  is that number 0?
 
 found 7 e8s0 entries
 
 Then it freezes.
 
 it's not the e820 code, then.  it's either falling over initializing the
 console, or it's falling over probing devices for the .ini file.
 
 after e820, 9load starts up the console and probes devices looking
 for a .ini file.
 
 i would think the odds are good that 9load has found an i/o port
 that should not be touched.  devices are probed in this order
   floppy. ether, cd, sd.
 
 i don't really have a kvm setup, but if it's possible, you might try
 removing devices (espeically ethernet devices) from a copy of 9load
 until you find something that boots, then add 'em back in till it doesn't.
 
 sounds tedious, no?  :-)

I'm perfectly willing. Two main problems at this point:

- I don't have immediate access to amd64 hardware to setup my own KVM/qemu.
I learned the hard way that KVM inside another qemu or VMware guest doesn't
work.
- Changing out the CD-ROM image on the hosted VPS requires sending an e-mail
to technical support and waiting up to 24 hours for a response. I've been told
allowing users to dynamically change CD-ROM images is not an option.

Jack:

If you reading this, do you want to try this with your cron-swapped floppy 
images?

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-05 Thread Jack

On 3/3/2011 9:20 AM, Stanley Lieber wrote:

The --no-kvm-irqchip option on the command line may have solved the problem.
 

This apparently did not work with my host's setup. Same results observed when
I halted and rebooted this VPS this morning.

The host reports they are running KVM/qemu on Ubuntu Jaunty 9.04. I'm in
the process of setting up a Linux machine so I can try to reproduce/solve the
problem locally.

-sl


   

Hello,

I'm one of the other people trying to get plan 9 on the same VPS host 
provider.  I've gotten past that hang.  Some haphazard print statements 
narrowed the hang down to the e820 init function in memory.c.  So to 
work around, setting either *noe820scan=1 or *norealmode=1 in plan9.ini 
will allow you to boot in that VPS without the aforementioned hang.
What the actual problem is, I don't know.  I'm fast approaching the end 
of my abilities, so you'll have to pick it up from there.

I'll know tomorrow how my install goes.
I do know where exactly it does hang, but it's my bedtime.  I'll have to 
drawterm into my cpu server and check my notes again to post where 
exactly the boot hung.


Cheers,
Jack



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-02 Thread Stanley Lieber
 The --no-kvm-irqchip option on the command line may have solved the problem.

This apparently did not work with my host's setup. Same results observed when
I halted and rebooted this VPS this morning.

The host reports they are running KVM/qemu on Ubuntu Jaunty 9.04. I'm in
the process of setting up a Linux machine so I can try to reproduce/solve the
problem locally.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-01 Thread Stanley Lieber
To recap:

I'm attempting to install Plan 9 from a recent .iso on a hosted KVM/qemu
account. Both the Bell Labs and 9atom installers die here:

http://farm6.static.flickr.com/5098/5468343552_28695be1dd_o.png

I've managed to obtain the host's KVM config file, in libvirtd XML format:

domain type='kvm' id='100'
  nameuser-2/name
  uuidREDACTED/uuid
  memory786432/memory
  currentMemory786432/currentMemory
  vcpu1/vcpu
  os
type arch='x86_64' machine='pc'hvm/type
boot dev='hd'/
  /os
  features
acpi/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashdestroy/on_crash
  devices
emulator/usr/bin/kvm/emulator
disk type='block' device='disk'
  source dev='/dev/vol1/user-2'/
  target dev='hda' bus='ide'/
/disk
disk type='file' device='cdrom'
  source file='/home/user/ISO/plan9.iso'/
  target dev='hdc' bus='ide'/
  readonly/
/disk
interface type='ethernet'
  mac address='52:54:00:27:34:07'/
  script path='/home/kvm-admin/scripts/attach-tap-to-vlan.sh'/
  target dev='tap0-407'/
  model type='e1000'/
/interface
serial type='tcp'
  source mode='bind' host='127.0.0.1' service='8081'/
  protocol type='telnet'/
  target port='0'/
/serial
console type='tcp'
  source mode='bind' host='127.0.0.1' service='8081'/
  protocol type='telnet'/
  target port='0'/
/console
input type='mouse' bus='ps2'/
graphics type='vnc' port='5981' autoport='no' listen=''/
  /devices
/domain

The actual KVM command is:

/usr/bin/kvm -S -M pc -m 768 -smp 1 -name user-2 -uuid 
101ff6a0-206b-012e-09d2-525400972102 -monitor pty -boot c -drive 
file=/dev/vol1/user-2,if=ide,index=0,boot=on -drive 
file=/home/user/ISO/plan9.iso,if=ide,media=cdrom,index=2 -net 
nic,macaddr=52:54:00:27:34:07,vlan=0,model=e1000 -net 
tap,ifname=tap0-407,script=/home/kvm-admin/scripts/attach-tap-to-vlan.sh,vlan=0 
-serial telnet:127.0.0.1:8081,server,nowait -parallel none -usb -vnc 
:81,password

Does anything here look obviously incorrect?

The hosting sevice is interested in offering Plan 9 services, so once
we get this working it may well be of use to others.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-01 Thread a z
I have plan9 running on a qemu installation, and I had a similiar problem
installing it.

The --no-kvm-irqchip option on the command line may have solved the problem.


I also may have walked away from the machine for 6 hours only to return and
find that it had installed, only to tear down the ubuntu distro
based VM and replace the thing with a gentoo kernel specifically for hosting
kvm.

The gentoo qemu + --no-kvm-irqchip  thing has definately kept the plan9.iso
installation online. Here is my command-line, its miniscule compared to
yours.

qemu-system-x86_64 --enable-kvm -net nic,macaddr=45:45:45:45:45:45 -net
tap,ifname=9tap,script=no,downscript=no -vga std --no-kvm-irqchip -vnc:1
-hda /home/kvm9/plan9.img -m 256 -daemonize

If you havent tried this already:
Or perhaps this, --no-kqemu since this is BSD complaining about an invalid
nvram checksum, other threads seem to indicate the CMOS layout error google
search pops on BSD across softwares.

http://qemu-forum.ipi.fi/viewtopic.php?f=7t=1921


On Wed, Mar 2, 2011 at 10:12 AM, Stanley Lieber stanley.lie...@gmail.comwrote:

 To recap:

 I'm attempting to install Plan 9 from a recent .iso on a hosted KVM/qemu
 account. Both the Bell Labs and 9atom installers die here:

 http://farm6.static.flickr.com/5098/5468343552_28695be1dd_o.png

 I've managed to obtain the host's KVM config file, in libvirtd XML format:

 domain type='kvm' id='100'
  nameuser-2/name
  uuidREDACTED/uuid
  memory786432/memory
  currentMemory786432/currentMemory
  vcpu1/vcpu
  os
type arch='x86_64' machine='pc'hvm/type
boot dev='hd'/
  /os
  features
acpi/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashdestroy/on_crash
  devices
emulator/usr/bin/kvm/emulator
disk type='block' device='disk'
  source dev='/dev/vol1/user-2'/
  target dev='hda' bus='ide'/
/disk
disk type='file' device='cdrom'
  source file='/home/user/ISO/plan9.iso'/
  target dev='hdc' bus='ide'/
  readonly/
/disk
interface type='ethernet'
  mac address='52:54:00:27:34:07'/
  script path='/home/kvm-admin/scripts/attach-tap-to-vlan.sh'/
  target dev='tap0-407'/
  model type='e1000'/
/interface
serial type='tcp'
  source mode='bind' host='127.0.0.1' service='8081'/
  protocol type='telnet'/
  target port='0'/
/serial
console type='tcp'
  source mode='bind' host='127.0.0.1' service='8081'/
  protocol type='telnet'/
  target port='0'/
/console
input type='mouse' bus='ps2'/
graphics type='vnc' port='5981' autoport='no' listen=''/
  /devices
 /domain

 The actual KVM command is:

 /usr/bin/kvm -S -M pc -m 768 -smp 1 -name user-2 -uuid
 101ff6a0-206b-012e-09d2-525400972102 -monitor pty -boot c -drive
 file=/dev/vol1/user-2,if=ide,index=0,boot=on -drive
 file=/home/user/ISO/plan9.iso,if=ide,media=cdrom,index=2 -net
 nic,macaddr=52:54:00:27:34:07,vlan=0,model=e1000 -net
 tap,ifname=tap0-407,script=/home/kvm-admin/scripts/attach-tap-to-vlan.sh,vlan=0
 -serial telnet:127.0.0.1:8081,server,nowait -parallel none -usb -vnc
 :81,password

 Does anything here look obviously incorrect?

 The hosting sevice is interested in offering Plan 9 services, so once
 we get this working it may well be of use to others.

 -sl





-- 
⎼⎺⎺├@┼␊├├≤-␍⎼␊▒␍:/␤⎺└␊/⎼␤⎺#


Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-01 Thread Stanley Lieber
 I have plan9 running on a qemu installation, and I had a similiar problem
 installing it.
 
 The --no-kvm-irqchip option on the command line may have solved the problem.
 
 
 I also may have walked away from the machine for 6 hours only to return and
 find that it had installed, only to tear down the ubuntu distro
 based VM and replace the thing with a gentoo kernel specifically for hosting
 kvm.
 
 The gentoo qemu + --no-kvm-irqchip  thing has definately kept the plan9.iso
 installation online. Here is my command-line, its miniscule compared to
 yours.
 
 qemu-system-x86_64 --enable-kvm -net nic,macaddr=45:45:45:45:45:45 -net
 tap,ifname=9tap,script=no,downscript=no -vga std --no-kvm-irqchip -vnc:1
 -hda /home/kvm9/plan9.img -m 256 -daemonize

Thanks, I'll experiment with these options.


 Or perhaps this, --no-kqemu since this is BSD complaining about an invalid
 nvram checksum, other threads seem to indicate the CMOS layout error google
 search pops on BSD across softwares.
 
 http://qemu-forum.ipi.fi/viewtopic.php?f=7t=1921

As far as I know, KVM/qemu is hosted on Linux. The dmesg in my previous e-mail
was OpenBSD booted on the same instance of KVM/qemu; primarily so I could
get an idea of what hardware KVM/qemu was presenting to the Plan 9 installer.

-sl




Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-03-01 Thread erik quanstrom
https://patchwork.kernel.org/patch/540521/

- erik



Re: [9fans] recent plan9.iso on hosted kvm/qemu

2011-02-24 Thread Eric Van Hensbergen
Dunno - but I did an install yesterday of a fresh ISO without problems
on Ubuntu 10.10 x86_64 with whatever their default KVM is.

 -eric


On Thu, Feb 24, 2011 at 7:40 AM, Stanley Lieber
stanley.lie...@gmail.com wrote:
 Both the install and live cd kernels die here:

 http://farm6.static.flickr.com/5098/5468343552_28695be1dd_o.png

 They just stop. Nothing further ever happens.

 Attached below is the OpenBSD dmesg from the same instance of
 KVM/qemu

 Anyone have any ideas on what might be going wrong?

 -sl

 ---

 OpenBSD 4.7 (GENERIC) #112: Wed Mar 17 20:43:49 MDT 2010
    dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
 real mem = 804192256 (766MB)
 avail mem = 770875392 (735MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfbd3f (10 entries)
 bios0: vendor QEMU version QEMU date 01/01/2007
 acpi0 at bios0: rev 0
 acpi0: tables DSDT FACP APIC
 acpi0: wakeup devices
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpicpu0 at acpi0
 mpbios at bios0 not configured
 cpu0 at mainbus0: (uniprocessor)
 cpu0: QEMU Virtual CPU version 0.9.1, 2667.07 MHz
 cpu0: 
 FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,LONG
 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
 64b/line 16-way L2 cache
 cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
 cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
 pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
 pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA, channel 0 
 wired to compatibility, channel 1 wired to compatibility
 wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
 wd0: 16-sector PIO, LBA48, 20480MB, 41943040 sectors
 wd0(pciide0:0:0): using PIO mode 0, DMA mode 2
 atapiscsi0 at pciide0 channel 1 drive 0
 scsibus0 at atapiscsi0: 2 targets
 cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 0.9. ATAPI 5/cdrom 
 removable
 cd0(pciide0:1:0): using PIO mode 0
 uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
 piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 10
 iic0 at piixpm0
 iic0: addr 0x18 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
 00= 01= 02= 03= 04= 05= 06= 07=
 iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
 00= 01= 02= 03= 04= 05= 06= 07=
 iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
 00= 01= 02= 03= 04= 05= 06= 07=
 iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
 00= 01= 02= 03= 04= 05= 06= 07=
 iic0: addr 0x48 48=00 words 00= 01= 02= 03= 04= 05= 
 06= 07=
 iic0: addr 0x49 48=00 words 00= 01= 02= 03= 04= 05= 
 06= 07=
 iic0: addr 0x4a 48=00 words 00= 01= 02= 03= 04= 05= 
 06= 07=
 iic0: addr 0x4b 48=00 words 00= 01= 02= 03= 04= 05= 
 06= 07=
 iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 48=00 
 words 00= 01= 02= 03= 04= 05= 06= 07=
 iic0: addr 0x4d 48=00 words 00= 01= 02= 03= 04= 05= 
 06= 07=
 iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 48=00 
 words 00= 01= 02= 03= 04= 05= 06= 07=
 vga1 at pci0 dev 2 function 0 Cirrus Logic CL-GD5446 rev 0x00
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 em0 at pci0 dev 3 function 0 Intel PRO/1000MT (82540EM) rev 0x03: irq 11, 
 address 52:54:00:27:34:07
 Qumranet Virtio Memory rev 0x00 at pci0 dev 4 function 0 not configured
 Qumranet Virtio Console rev 0x00 at pci0 dev 5 function 0 not configured
 isa0 at pcib0
 isadma0 at isa0
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com0: probed fifo depth: 0 bytes
 pckbc0 at isa0 port 0x60/5
 pckbd0 at pckbc0 (kbd slot)
 pckbc0: using irq 1 for kbd slot
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pmsi0 at pckbc0 (aux slot)
 pckbc0: using irq 12 for aux slot
 wsmouse0 at pmsi0 mux 0
 pcppi0 at isa0 port 0x61
 midi0 at pcppi0: PC speaker
 spkr0 at pcppi0
 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
 fd0 at fdc0 drive 0: density unknown
 fd1 at fdc0 drive 1: density unknown
 usb0 at uhci0: USB revision 1.0
 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1
 nvram: invalid checksum
 mtrr: Pentium Pro MTRR support
 vscsi0 at root
 scsibus1 at vscsi0: 256 targets
 softraid0 at root
 root on wd0a swap on wd0b dump on wd0b
 clock: unknown CMOS layout