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

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

[Stanley Lieber]

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
    deraadt@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 0xfee00000: 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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x48 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x49 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x4a 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x4b 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x4d 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
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

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

[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.lieber@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
>    deraadt@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 0xfee00000: 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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x48 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x49 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x4a 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x4b 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> 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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> iic0: addr 0x4d 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> 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=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> 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
>
>
>

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

[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

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

[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

[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

[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 <quanstro@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

[Jack Norton]

erik quanstrom wrote:
> On Sun Mar  6 22:33:33 EST 2011, stanley.lieber@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
>

Well I've got some other observations of interest.
As I mentioned, I installed with *noe820scan=1 successfully.
I was in the middle of configuring and playing around when I realized I
had no ethernet car.  bind -a '#l' /dev returned 'no free devices'.

The vps has an e1000 card (PRO/1000) plugged into it, so I naively put
"ether0=type=igbe" in plan9.ini.
Now it hangs right where 9load would normally say "no ethernet devices
found" or something similar.

How odd.

-Jack

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

[erik quanstrom]

On Mon Mar  7 12:06:34 EST 2011, stanley.lieber@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

[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

[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

[Jack Norton]

Stanley Lieber wrote:
>> On Sun Mar  6 22:33:33 EST 2011, stanley.lieber@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

[Stanley Lieber]

> On Sun Mar  6 22:33:33 EST 2011, stanley.lieber@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

[erik quanstrom]

On Sun Mar  6 22:33:33 EST 2011, stanley.lieber@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

[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

[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

[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

[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

[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 100000 cfedeff0 100000000 130000000 '

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 100000 cf000000

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

[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

[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

[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

[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

[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=7&t=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

[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'>
  <name>user-2</name>
  <uuid>REDACTED</uuid>
  <memory>786432</memory>
  <currentMemory>786432</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</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

[erik quanstrom]

https://patchwork.kernel.org/patch/540521/

- erik

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

[a z]

[-- Attachment #1: Type: text/plain, Size: 3715 bytes --]

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=7&t=1921


On Wed, Mar 2, 2011 at 10:12 AM, Stanley Lieber <stanley.lieber@gmail.com>wrote:

> 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'>
>  <name>user-2</name>
>  <uuid>REDACTED</uuid>
>  <memory>786432</memory>
>  <currentMemory>786432</currentMemory>
>  <vcpu>1</vcpu>
>  <os>
>    <type arch='x86_64' machine='pc'>hvm</type>
>    <boot dev='hd'/>
>  </os>
>  <features>
>    <acpi/>
>  </features>
>  <clock offset='utc'/>
>  <on_poweroff>destroy</on_poweroff>
>  <on_reboot>restart</on_reboot>
>  <on_crash>destroy</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
>
>
>


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

[-- Attachment #2: Type: text/html, Size: 5264 bytes --]