On Sat, Mar 17, 2007 at 02:09:24PM -0400, Greg Saunders wrote:
>
> >If eth0 is a PCI card, then just remove the allow-hotplug stuff. If
> >you've got a hotplug PCI system, you can always work out if/how to put
> >the allow-hotplug back in later.
>
> To be honest, I don't know that eth0 is a PCI card, but I suspect it is. I
> do know that the computer is a laptop (Dell Inspiron 6400 with Core 2 Duo,
> much like the one reviewed at
> http://www.reghardware.co.uk/2006/12/06/review_dell_inspiron_6400/), and I
> do know that eth0 is not a PCMCIA card - the computer doesn't even have a
> PCMCIA slot.
>
That sounds about right. I've got an inspiron here, there will always be
an onboard nic on those things. I did a quick search on the oui part of
the MAC addreess below 00:15:C5 and I it appears to be registered to
Dell.
> >
> >To summarize:
> > . Explain what eth0 is and what eth1 is (wireless, PCI, etc)
>
> I am under impression that eth0 is my "not-wireless" network interface
> card; not to be confused with wlan0, my wireless network interface card,
> mention of which I had completely removed from /etc/network/interfaces.
>
> As for what eth1 is - I hadn't noticed it before and I had assumed it was
> something to do with the Xen installation. Given that you're asking,
> though, I wonder now if it's something to do with another foray I've
> recently made into virtualisation: I have installed the Qemu and have had a
> virtual machine running on that. (That experiment is over now, though, and
> I was going to remove Qemu.)
>
I'd be very surprised if it was related to qemu. I'm messing around with
qemu and kvm at the moment and I don't see anything like that. Qemu's
user mode networking stack would not be allowed to create interfaces
like that on the host, and if your using tuntap interfaces, these
will look like normal ethernet interfaces. Anyway, the good news is that
eth1 is there - and still strange looking - when you run etch with a
non-xen kernel. It's probably not something we need to worry about here.
> > . Try again using the timeout settings in interfaces.
>
> Done. No difference. After making /etc/network/interfaces look like this
> (note change from "xenbr0" to "xbr0" and lack of "allow-hotplug") :
>
> auto lo
> iface lo inet loopback
>
> iface xbr0 inet dhcp
> bridge_fd 0
> bridge_maxwait 0
> bridge_helo 0
> bridge_ports eth0
>
> auto xbr0
>
That's a pity!
<snip/>
> And ifconfig -a returns
>
> eth1 Link encap:UNSPEC HWaddr
> 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
<snip/>
>
> For comparison, it might tell you something to see that when I run my
> original Etch kernel and make my /etc/network/interfaces looks this:
>
<snip/>
> So that ifconfig -a returns
>
> eth0 Link encap:Ethernet HWaddr 00:15:C5:C9:F6:E3
> inet addr:192.168.0.102 Bcast:192.168.0.255 Mask:255.255.255.0
> inet6 addr: fe80::215:c5ff:fec9:f6e3/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:72 errors:0 dropped:0 overruns:0 frame:0
> TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:18210 (17.7 KiB) TX bytes:5002 (4.8 KiB)
> Interrupt:58
>
> eth1 Link encap:UNSPEC HWaddr
> 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
Thanks Greg, this comparison was very helpful. The problem here is
clearly that eth0 does not exist when you boot into xen. It's not a
problem with bridging, or anything like that. If you were to use an
empty /etc/network/interfaces file and you were to prevent xend from
running at startup:
# find /etc/rc*.d -name '*xend'
/etc/rc0.d/K21xend
/etc/rc1.d/K21xend
/etc/rc2.d/S20xend
/etc/rc3.d/S20xend
/etc/rc4.d/S20xend
/etc/rc5.d/S20xend
/etc/rc6.d/K21xend
# find /etc/rc*.d -name '*xend' | rename s/S20/K80/
# find /etc/rc*.d -name '*xend'
/etc/rc0.d/K21xend
/etc/rc1.d/K21xend
/etc/rc2.d/K80xend
/etc/rc3.d/K80xend
/etc/rc4.d/K80xend
/etc/rc5.d/K80xend
/etc/rc6.d/K21xend
And you rebooted. You would still not see eth0. You can try this if you
want (but remember to do a 'rename s/K80/S20/' afterwards).
If you can get eth0 to exist under xen then all that bridging stuff will
fall into place. So how do you do that? Well, I recommend you try the
following.
Boot into etch with the none-xen kernel running. Now collect all the
information you can about you network card:
$ udevinfo -ap /sys/class/net/eth0/ > eth0.notes
You are particularly interested in what driver is running for eth0:
$ udevinfo -ap /sys/class/net/eth0/ | grep -i driver
DRIVER=="b44"
DRIVER==""
DRIVER==""
Also run 'lspci' and collect the information you receive in case you
need to search google.
Then boot back into xen and try to load the driver manually.
$ modprobe b44
Check the output of udevinfo here as well, and check log files and just
generally try to work out what has happened to eth0.
>
> > . Also, do you have physical access to this machine or is it in a
> > remote hosting center? If you've got physical access then we can step
> > through creating a bridge manually - not something you really want to
> > try when logged in remotely :-)
>
> I do have physical access to the machine.
>
Good, but unfortunatly I can't step you through the manual creation
of the bridge if eth0 does not exist. And if it did exist the bridge
stuff would probably be working just fine anyway. Damn!
jez
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home