Paul Ankers's picture

Trying to get live Ruby on Rails up & going, just get to config console and get above message. What might be the problem here? Thanks in advance.

Forum: 
Liraz Siri's picture

For some reason it seems the network interfaces on your machine or virtual machine are not being detected by the configuration console and/or the operating system. Try to see what network interfaces the operating system can see with this command:
ifconfig -a
Jeremy Davis's picture

@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.

Liraz Siri's picture

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...

Jeremy Davis's picture

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?

Jeremy Davis's picture

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?

Liraz Siri's picture

I'll bet if this is specific to the VM builds it has something to do with the virtualization optimized Ubuntu kernel. It would be great if those experiencing issues could attempt to reproduce it on an ISO appliance installation that has the regular Ubuntu kernel.
Alon Swartz's picture

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"
 

 

Matthew Hargreaves's picture

 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

 

Liraz Siri's picture

I've been wracking my brain trying to figure out what might be going wrong in these reports. If a freshly unzipped appliance works while an older instance fails to detect the NIC then perhaps there is something in the state of the instance that is causing the problem. If we can figure out what changed between the time the instance was installed to when the NIC disappeared that brings us much closer to finding the root cause and fixing it.

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.

peter's picture

You should be able to get my details now, if you'd like me to send you the broken instance let me know.

 

pete

 

Alon Swartz's picture

About a week ago I launched a VM build running on VMWare server with the sole purpose of reproducing this issue. The VM was Torrent Server and has been downloading/uploading ever since without any networking issues (unfortunately or not, depending on how you look at it).

Anyway, I'd like to second what Liraz said: 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.
Jeremy Davis's picture

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!

peter's picture

All seems to work fine with a "normal" upgrade.
you are absolute write "don't fix it if it's not broken!" is a golden rule.
its the mass consumer  in me that wants "Newer, fast, better, more, more, more" that made me do the dist-upgrade

Thought the info might help.

Pete

Ps. love turnkey's work, keep it up.

 

Jeremy Davis's picture

Having come from the Windows world where that's the name of the game (better, faster, stronger, but more often than not just more bells and whistles!) I can really relate to that.

Although the irony is that even a dist-upgrade, AFAIK it will only upgrade to the next OS, so to get to the currnt version of Ubuntu (9.10), you'd need to dist-upgrade 3 times!

Alon Swartz's picture

Finally, one of my test VM's networking broke on a reboot - Yay! I've never been so happy to see error messages... :)

I'm still not sure what is causing this issue, but I think I got the fix/workaround. I need your help testing:

1. Remove the following line from turnkey-APP.vmx
Ethernet0.virtualDev = "vmxnet"
This will cause the network adapter device type to become "flexible".

2. If you are using VMWare server, unregister then register the VM so the vmx change takes effect.

Let us know how it goes...
peter's picture

Goes well with me. 

by removeing that line form the .vmx file my broken vm (after the dist-upgrade) is back to life!

VMware player asked  if the VM had need moved or copyed. i said moved.

it was never in uses or deployed so after the dist-upgrade i have no idea if its all functionality is 100%,  but the VNIC is back and all seems to work!

Pete

Matthew Hargreaves's picture

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

 

Matthew Hargreaves's picture

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

Jeremy Davis's picture

TBH I have no idea what would cause that and it's not something that I have ever encountered. In my experience, things either "just work" in Linux or they don't. If they don't you need to dig in deep and bring your best google-fu! But once you get them working, in my experience they generally keep working (until/unless a kernel upgrade breaks manually implemented drivers).

I suggest that a good place to start would be consulting your syslog around the time that the NICs disappeared. That may explain what happened? Also check to see if your system is still seeing the hardware and just not loading the drivers for some reason; or whether it can't even see the hardware. Then check your hardware and find the correct/ideal driver. Perhaps the driver that your system was using originally was sub-optimal and there is a better driver to use?

Bottom line is that I expect this will be a big job so either plan to spend a fair bit of time googling, reading and trying things out; or hire someone who does this stuff everyday to troubleshoot and resolve your issue.

You didn't mention the distro that you are using but if it's TurnKey then v14.x = Debian Jessie. Anything that applies to Jessie generally applies to TurnKey. Instructions relating to Ubuntu (also based on Debian) shoudl generally apply too, but not always...

Add new comment