ifconfig -a

@Larry & Ron - Sound like you guys are experiencing the same problem. I am sure this is to do with the virtual networking setup on your Host (although I could be wrong - Larry you didn't specify whether you were running in a VM environment). I suspect that you had your wifi configured correctly but for some reason your wired connection isn't being offered to the VM platform you are using (and hence TKL can't find an interface).

For troubleshooting it may be useful to try installing another VM using an alternative OS (such as Ubuntu desktop, etc) to see if this behaves the same.

You may be able to get some assistance by looking at the documentation of your VM environment software.

To help others to help you, more information is required. I would suggest at a minimum you should list your host OS and the VM environment you are using (eg VirtualBox, VMware, KVM etc). Its probably also helpful if you can detail what you have tried.

Larry and Ron unfortunately didn't register for user accounts so it won't be easy to contact them for further information.

Without further information we can't try to replicate this behavior so we can't tell if it's a defect in the appliance, or in the virtual networking configuration, etc.

Since the operating system isn't detecting the VMs NICs at all, I agree with JedMeister's conclusions that it's probably a virtual networking issue that needs to be resolved with the virtualization program. If that's the case then we can't fix something like that at the appliance level.

I may be wrong though. We need more information. What virtualization program does this happen on? What steps do we need to carry out to replace this problem? Etc...

Is this perhaps the same issue as documented here by Alon? (Discovered and initial workaround identified here). Can one of you guys experiencing this issue try the fix and report back?

By this sounds of it, this may be a problem a fair few are experiencing. To help the devs nail it down it may be useful to test installing from the ISO (assuming you are using the VM image) to see if its something to do with the way TKL interfaces with VMWare or just limited to the VM image.

As the only two people in this thread who have stated their running environments are using VMWare products, maybe its worth giving VirtualBox a go (or even MS VirtualPC - assuming the VM image is compatible with that to).

This seems to be a problem that has increased in incidence with the 2009.10 release, Maybe that is because of a bug in the VM images? Or maybe its just because more ppl using TKL?

This is a shot in the dark, but assuming this issue only happens in VM builds, it might be related.

Could you please try the following, then reboot:

1. Delete /etc/udev/rules.d/70-persistent-net.rules

2. Create /etc/udev/rules.d/75-persistent-net-generator.rules

# these rules generate rules for persistent network device naming
#
# variables used to communicate:
#   MATCHADDR             MAC address used for the match
#   MATCHID               bus_id used for the match
#   MATCHDRV              driver name used for the match
#   MATCHIFTYPE           interface type match
#   COMMENT               comment to add to the generated rule
#   INTERFACE_NAME        requested name supplied by external tool
#   INTERFACE_NEW         new interface name returned by rule writer

ACTION!="add", GOTO="persistent_net_generator_end"
SUBSYSTEM!="net", GOTO="persistent_net_generator_end"

# ignore the interface if a name has already been set
NAME=="?*", GOTO="persistent_net_generator_end"

# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"

# ignore Xen virtual interfaces
SUBSYSTEMS=="xen", GOTO="persistent_net_generator_end"

# read MAC address
ENV{MATCHADDR}="$attr{address}"

# match interface type
ENV{MATCHIFTYPE}="$attr{type}"

# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""

# build comment line for generated rule:
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($driver)"
SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($driver)"
SUBSYSTEMS=="pcmcia", ENV{COMMENT}="PCMCIA device $attr{card_id}:$attr{manf_id} ($driver)"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"

# S/390 uses id matches only, do not use MAC address match
SUBSYSTEMS=="ccwgroup", ENV{COMMENT}="S/390 $driver device at $id", ENV{MATCHID}="$id", ENV{MATCHDRV}="$driver", ENV{MATCHADDR}=""

# see if we got enough data to create a rule
ENV{MATCHADDR}=="", ENV{MATCHID}=="", ENV{INTERFACE_NAME}=="", GOTO="persistent_net_generator_end"

# default comment
ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device"

# write rule
DRIVERS=="?*", IMPORT{program}="write_net_rules"

# rename interface if needed
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"

 I'd like to give this a go, and cut-and-paste the text in your post.  Problem is I can't cut and paste, and I can't get "shared folders" working.  Probably a result of the nic not working. I don't trust myself to type it correctly.   I did download the .ISO image so I'll try that.

Thanks for the help,   I'll let you know.   Matt

Latest - Downloaded Sun VirtualBox, imported, and no problems at all.  So a problem associated with VMWare.  I'll let you know how virualbox goes.

Matt

Note that we run the virtual appliances in VMWare Server all the time and haven't come across this problem. Maybe we're doing it differently somehow.

Long story short I'd like the opportunity to try and examine a "broken" instance. If someone manages to reproduce this consistently with Core it would be extremely helpful if they could upload the broken virtual appliance to a free file hosting service and post the url here.

If this is only happening after an upgrade then it may be an Ubuntu bug. Although theoretically an upgrade should work and shouldn't break anything, that is not always the way it works.

Personally I generally avoid apt-get upgrade. In general there is no need to upgrade anything unless there is a security risk, a bug you need fixed (which an upgraded version of something fixes) or there is a new feature that you want/need. This is especially the case with TKL appliances as they auto update security issues.

How does it go if you don't do an upgrade?

[edit] I just noticed that you said you did a "disubution upgrade". I am not surprised that broke something! TKL appliances are based on 8.04.3. When you do a distribution upgrade, you are actually upgrading your Linux install to 8.10, so its not really TKL anymore! Its an Ubuntu 8.10 Server with custom TKL setup designed for 8.04.3!

So I would personally avoid upgrade, and definately don't do dist-upgrade!

Ethernet0.virtualDev = "vmxnet"

Hi,

I have been successfully developing on the TKL image for over a week now - using Sun's virtual box.  Converting to virtualbox overcame the problem.

Decided I wanted to contintue development on another PC, so

shut it down;  Did a virtual box export of the image to a  place on my network, went to the other PC, and did a virtual box import, and then booted the VM.  Voila. It runs.  It detects the interface.  It brings the interface up.  But.... it fails to recieve any packets, and therefore fails DHCP config.

UP BROADCAST RUNNING MULTICAST

RX PACKETS:0
TX PACKETS:12

Have rebooted a couple of times.  No change. 

Staticly set an IP-addr, and default route, ping'd but "host unreachable" (still no packet received - ifconfig)

Not sure if this is related to previous.  Will try the change to turnkey-APP.vmx.

Thanks , Matt

Going on a search of a .VMX file (in the Sun Virtual Box installation) lead  to investigate the configuration.  The interface config had somehow flipped to map to a network adapter I don't use (a wifi one).  Once configured back to my bridged ethernet, all's well....
Thanks, Matt