Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I installed Ubuntu 13.10 server (64-bit) in a VirtualBox 4.3.6 VM (Windows host) with one NAT adapter assigned. The only non-default software selected during installation was OpenSSH. So far so good... I could ping the world and the address is 10.0.2.15 as would be expected (per ifconfig the NAT adapter is eth0 at this point).

I want to access the VM via the host without any port-mapping. Since bridging isn't an option (I can't get a second direct IP from outside the host) I created a host-only adapter (with DHCP enabled and all), edited /etc/network/interfaces (duplicating the eth0 defaults for eth1), shut the VM down, attached the new host-only adapter (selected paravirtualized), and rebooted.

At this point /etc/network/interfaces contained the following:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

And indeed it all works... but per ifconfig the NAT adapter is now eth1, while the newly-added host-only adapter is eth0. I want it the other way around - and that leads to all kinds of problems!

First I tried adding the MAC addresses to the interfaces file, e.g., "hwaddress ether xx:xx:xx:xx:xx:xx" as I expect it to be for eth0 and eth1. No joy... that ends up breaking networking entirely. I commented out those lines and rebooted (I actually had to disable that host-only adapter and reboot again, then I could finally re-enable it... this may be a clue.)

Reading further, I see many references to updating /etc/udev/rules.d/70-persistent-net.rules to swap the MAC addresses. Great idea! Except that other than a README file /etc/udev/rules.d is completely empty. I tried "sudo udevadm trigger" (and a few permutations thereof)... no change.

So question #1: what happened to 70-persistent-net.rules? Is that deprecated? /etc/udev/rules.d is empty except for a README file.

Next, I tried the following:

sudo ifconfig eth0 down sudo ifconfig eth1 down sudo ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx sudo ifconfig eth1 hw ether yy:yy:yy:yy:yy:yy sudo ifconfig eth0 up sudo ifconfig eth1 up

Hmm. ifconfig now reports the expected mac addresses but the IP addresses are still as they were. So I reboot...

And again, networking is broken (it is around this point that one learns the merit of editing /etc/init/failsafe.conf to shorten network delays during the networking debug process). The contents of /etc/network/interfaces are unchanged from how they look above. ifconfig now reports that eth0 and eth1 have the same (NAT adapter MAC) address even though I really did swap the MAC addresses above. Restore the MACs per the same procedure and reboot and we're back where we started (eth0 = host-only and eth1 = NAT).

Therefore, the main question is: how do you swap eth0 and eth1 correctly on Ubuntu 13.10? On CentOS (given DHCP) it was as easy as swapping the MAC addresses in /etc/sysconfig/network-scripts/ifcfg-eth0 and ifcfg-eth1 and then rebooting. On Ubuntu it's like pulling teeth... everything that should work won't work, and I am stumped. I suspect there's something relatively new going on under the hood (thus the "missing" rules files and so on) but what could it be? Note that the network-manager isn't installed by default either (and it's definitely not present).


Update: Just for grins I created another VM with the same default server setup (including OpenSSH as before), with one network adapter (NAT). No change - networking works as it normally would for this configuration, but there's nothing in /etc/udev/rules.d except a README file (I even checked as root... nothing).

share|improve this question
1  
Do you have /lib/udev/write_net_rules and /lib/udev/rules.d/75-persistent-net-generator.rules ? They are in 13.04 as part of the udev pkg. They are what generate /etc/udev/rules.d/70-persistent-net.rules if it doesn't exist. –  Mark Plotnick Jan 16 at 23:01
    
Yep, and I get the "missing $INTERFACE" error that's mentioned out there as well... it's rather frustrating. –  MartyMacGyver Jan 17 at 0:13
1  
You'll get that error from write_net_rules unless the proper environment vars are set. On my 13.04 system, 75-persistent-net-generator.rules sets those vars, and is run at boot time. I don't know what triggers it. –  Mark Plotnick Jan 17 at 0:53
    
AHA! It's because this is a VM... I'll update my post or add an answer but now I know why that file wasn't getting generated. –  MartyMacGyver Jan 17 at 1:11
    
Thank you again, @MarkPlotnick - you suggestions led me to examine that generator in detail, which led to my discovering the answer. –  MartyMacGyver Jan 17 at 1:37

1 Answer 1

up vote 0 down vote accepted

Well, I have at least a partial answer so far.

As I said, this is in a VM. The VM creates special MAC addresses of the form 08:00:27:xx:yy:zz. Along with several other scripts, I took a look at /lib/udev/rules.d/75-persistent-net-generator.rules to see if the problem was in there. Turns out, that's one of several excluded address ranges specifically mentioned in that file (it tries to ignore virtual interfaces)!

So, to test that theory I commented out the line in that file, rebooted and presto! /etc/udev/rules.d/70-persistent-net.rules gets generated with the MAC of the interface I currently have.

Next up: testing whether updating this alone and rebooting solves the problem. I'll update when I've gotten that tested.

Update: That was it! I removed the test fix and the generated file, shut down, added the second host-only network adapter and rebooted. The new adapter got enumerated first as eth0, and the NAT one then became eth1. I re-did the edit to the generator to remove the exclusion, rebooted and now I had a persistent rules file to work with.

In that file I simply swapped the device names (I changed NAME="eth0" to "eth1" and vice versa), saved, rebooted and voila - it worked!

Now, if you had entered MAC addresses elsewhere you'd want to correct those as well, but in this case it was very straightforward.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.