From: Jerome Ibanes <jibanes@eskimo.com>
To: 9fans@9fans.net
Subject: [9fans] Netbooting from Qemu
Date: Thu, 17 Sep 2009 16:10:55 -0700 [thread overview]
Message-ID: <Pine.SUN.4.58.0909171547410.8301@eskimo.com> (raw)
Hi,
I am (net)booting a Qemu instance from a Plan 9 fileserver named
colossus(192.168.1.40) running cwfs, an authserver, named
cerberus(192.168.1.50) is also present in the same domain.
The client is named cpu-003(192.168.1.33), it retrieves, via dhcp its
plan9.ini, which is as such:
bootfile=ether0!/386/9pccpu.gz
bootargs=tcp!192.168.1.40!564 -D
fs=192.168.1.40
auth=192.168.1.50
sysname=cpu-003
*nomp=1
*debugload=1
*nodumpstack=1
The dhcpd configuration uses /lib/ndb/local to properly serve dhcp
queries, relevants bits as follow:
ipnet=drawterm.com ip=192.168.1.0 ipmask=255.255.255.0
dnsdomain=drawterm.com
authdom=drawterm.com
ipgw=192.168.1.1
dns=192.168.1.1
ntp=192.168.1.1
auth=cerberus
fs=colossus
cpu=cpu-001
smtp=192.168.1.1
ip=192.168.1.33 sys=cpu-003 ether=525400123456
dom=drawterm.com
bootf=/386/9pxeload
proto=tcp
When booting a 9pc kernel (which means that bootfile=ether0!/386/9pc.gz)
the system boots, then prompt for a user login, secstore password and
behaves as a terminal, as one can expect.
When booting a 9pccpu kernel (with the configuration above, and not
another change from the 9pc kernel) the system hangs as such (please
notice that I have ipconfig debug mode turned on in the bootargs):
[...]
ipconfig: parsebootp: new packet
ipconfig: parseoptions: type(53) len 1, bytes left 71
ipconfig: parseoptions: lease(51) len 4, bytes left 68
ipconfig: parseoptions: serverid(54) len 4, bytes left 62
ipconfig: parseoptions: ipmask(1) len 4, bytes left 56
ipconfig: parseoptions: ipgw(3) len 4, bytes left 50
ipconfig: parseoptions: sys(12) len 12, bytes left 44
ipconfig: parseoptions: dns(6) len 4, bytes left 30
ipconfig: parseoptions: dom(15) len 3, bytes left 24
ipconfig: parseoptions: ntp(42) len 4, bytes left 19
ipconfig: parseoptions: <nil>(43) len 12, bytes left 13
ipconfig: got ack from 192.168.1.40
ipconfig: lease=1800
ipconfig: ipaddr=192.168.1.33 ipmask=255.255.255.0
ipconfig: ipgw=192.168.1.1
ipconfig: dns=192.168.1.1
ipconfig: ntp=192.168.1.1
ipconfig: parseoptions: <nil>(128) len 4, bytes left 10
ipconfig: parseoptions: <nil>(129) len 4, bytes left 4
ipconfig: fs=192.168.1.40
ipconfig: auth=192.168.1.50
ipconfig: new ipaddr=192.168.1.33 new ipmask=255.255.255.0 new ipgw=192.168.1.1
ipconfig: server=192.168.1.40 sname=colossus
Then the system hangs, the cwfs console reports that no connection was
established from cpu-003(192.168.1.33), while, when booting a 9pc kernel,
the connection is established and the boot sequence follows.
Finally, replacing 'tcp!192.168.1.40!564' by 'tcp' or 'tcp!colossus!564'
leads to the same results, I do not believe it to be a misconfiguration
however as 9pc is booting properly.
Despite that 9pccpu is hanging, I am able to ping this host
cpu-003(192.168.1.33) therefore the network card has been found and
initialized properly. A 'snoopy' reports that after the last dhcp queries,
no packets are ever sent from cpu-003(192.168.1.33).
What would cause this configuration to boot using a stock 9pc kernel but
not a 9pccpu one? I've even increased the memory allocation of the Qemu
instance as I would expect a 9pccpu kernel to be slightly bigger than a
9pc one.
Any suggestion?
Jerome
next reply other threads:[~2009-09-17 23:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-17 23:10 Jerome Ibanes [this message]
2009-09-17 23:54 ` erik quanstrom
2009-09-18 15:30 ` Jerome Ibanes
2009-09-18 15:42 ` erik quanstrom
2009-09-18 16:09 ` Steve Simon
2009-09-18 17:55 ` Tim Newsham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.SUN.4.58.0909171547410.8301@eskimo.com \
--to=jibanes@eskimo.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).