Cloning Debian Etch guest breaks networking

[Theodore Ruegsegger]

See also ticket #645 which says that taking a snapshot breaks networking.

On a Kubuntu Feisty host using VirtualBox 1.5 (and 1.4 before with the same result) I created a Debian Etch guest. Then I cloned the disk and used it to create a new virtual machine, but networking fails in the new machine (eth0 just won't come up).

On the original machine, starting networking reports, among other stuff, that eth0 is up at 100MB, Full-Duplex.

On the cloned machine it just says:

Configuring network interfaces...done.

and all I have is lo. If I try ifup eth0, I get:

[boilerplate omitted]
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Bind socket to interface: No such device
Failed to bring up eth0.

I've tried this numerous times, starting from scratch. The same thing happens whether I use NAT or bridging.

Things I've tried that have failed to solve the problem:

• Rebooting the guest.
• Power-cycling the guest.
• modprobe -r pcnet32 ; modprobe pcnet32
• Not installing guest additions
• Installing guest additions.
• Not installing anything beyond the minimum Debian system.

Haven't tried it with any Guest other than Debian Etch.

[Theodore Ruegsegger]

For what it's worth, I tried cloning a Kubuntu Feisty guest but had no problem with networking.

I should add, in case it makes a difference, that my Debian Etch guest had no X11 installed, since I intended to use it for a server.

[Theodore Ruegsegger]

Aha! Found something that does work:

In settings/network/MAC Address, I made sure the Etch clone had the same MAC address as the original. This time it came up and the network worked!

This suggests that Debian retains the MAC address somewhere and refuses to recognize a network device with a different MAC address. I'd be surprised if this happens with real hardware, though, or no one could ever swap out a NIC. If it does, then the problem lies with Debian Etch rather than VirtualBox, but I doubt it. Perhaps there's some tool I need to run to change NICs...

So keeping the MAC address constant is a workaround, but it means I can't run two such machines at the same time, which loses much of the value of virtualization.

Any suggestions welcome!

FWIW, Kubuntu Feisty, even though a Debian derivative, networks fine with a changed MAC address.

[Frank Mehnert]

Debian etch uses a special udev rule to assign a MAC the same ethx interface (see /etc/udev/rules.d/rules.d/z25_persistent-net.rules which is generated by /etc/udev/persistent-net-generator.rules). Changing the MAC only means changing the eth interface, therefore try eth2, eth3 or something. dmesg should tell you the name.

[Theodore Ruegsegger]

Thanks for this valuable insight which gets me much further in solving my problem.

I'm not quite clear what you're telling me: when you say "therefore try eth2, eth3 or something" do you mean in the guest or in the VirtualBox settings? I examined dmesg in the guest and saw that it detected the NIC:

pcnet32: PCnet/FAST III 79C973 at 0xc020, 08 00 27 68 fd b5 assigned IRQ 11. pcnet32: Found PHY 0000:0000 at address 0. eth0: registered as PCnet/FAST III 79C973 pcnet32: 1 cards_found.

Some lines later it repeats the above. It looks like it's finding eth0, with the right MAC address (for this test, I added 1 to the MAC address from the original).

Then I examined /etc/udev/rules.d/rules.d/z25_persistent-net.rules and found an entry for the original MAC address as well as another for the new MAC address (as eth3), and one for all the addresses I've tried in-between.

I'm not sure how to proceed from here:

1. Can I regenerate /etc/udev/rules.d/rules.d/z25_persistent-net.rules to use just the MAC address I want, as eth0? If so, how? Or do I just edit it and reboot?

2. If I wanted to use eth3, how would I activate it? ifup eth3 just says:

Ignoring unknown interface eth3=eth3.

Thanks very much for taking the time to help with what turns out, after all, not to be a VirtualBox bug. When I understand it fully (with a bit more of your help), I'll post the results to the thread in the Wiki.

[Frank Mehnert]

For a virtual machine I would just remove that persistent rule since it makes more sense with a real PC.

To use an other interface than eth0 have a look at /etc/network/interfaces: An entry

iface eth0 inet dhcp
auto eth0

enables eth0. Add entries for eth1, eth2 and so on to enable other interfaces as well. But careful: Enabling them may lead to longer boot times since the guest will try to receive an DHCP lease (because of the 'auto ethx' entry).

[Theodore Ruegsegger]

Wow, thanks for the quick response!

To remove the rule, should I edit /etc/udev/rules.d/rules.d/z25_persistent-net.rules to remove the offending lines, or is it safe just to delete the file and let it be regenerated (presumably after a reboot)?

Regarding /etc/network/interfaces, I blush that I didn't think of that myself.

I've learned a great deal this morning!

[Frank Mehnert]

Better: Look at the file /etc/udev/persistent-net-generator.rules. There is already a rule to ignore VMware interfaces from generating a persistent rule. Just add after the VMware rule

# ignore VirtualBox virtual interfaces
ATTR{address}=="08:00:27:*", GOTO="persistent_net_generator_end"

Finally remove /etc/udev/z25_persistent-net.rules. Don't change /etc/network/interfaces. Reboot your guest and the interface should be well-detected.

[Theodore Ruegsegger]

Now that's elegant! And I can do it right in the original template box so all the clones will just work.

Just to be clear, I think you meant /etc/udev/rules.d/z25_persistent-net.rules

(You left out "rules.d/", perhaps because in all my posts I put it in twice!)

Oddly enough, my Etch has no VMware rule, at least not in /etc/udev/persistent-net-generator.rules, but your advice still stands. That explains why, when I tried it in VMware, I had the same problem. I'm guessing the rule would look just like the VirtualBox one except that the signature is "00:0c:29":

# ignore VMware virtual interfaces ATTR{address}=="00:0c:29:*", GOTO="persistent_net_generator_end"

[maddes.b]

This bug is described in ​Debian Bug#431190 for VMWare. The fix is available in Lenny, which is currently the testing release and not the stable release.

Here is the content of /etc/udev/persistent-net-generator.rules from ​udev 0.114-2:

# do not edit this file, it will be overwritten on update

# these rules generate rules for persistent network device naming

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

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

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

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

# build device description string to add a comment to the 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=="ccwgroup", ENV{COMMENT}="S/390 $driver device at $id", ENV{NETDEV}="$id", ENV{NETDRV}="$driver"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($driver)"

DRIVERS!="?*", ENV{NETDEV}=="?*", IMPORT{program}="write_net_rules --driver $env{NETDRV} --id $env{NETDEV}"

# skip "locally administered" MAC addresses
ATTR{address}=="?[2367abef]:*", GOTO="persistent_net_generator_end"

DRIVERS!="?*", ENV{NETDEV}!="?*", IMPORT{program}="write_net_rules $attr{address}"
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"

This script works fine for me with VirtualBox 1.5.6. But do not forget to clean up /etc/udev/rules.d/z25_persistent-net.rules by removing all memorised VM nics.

[Mathias De Maré]

I have pretty much the same problem, running an Ubuntu 8.04 (Hardy) 32-bit guest on an Ubuntu 8.10 64-bit host (see also ​http://forums.virtualbox.org/viewtopic.php?t=12060 ).

I've added the following to /etc/udev/rules.d/75-persistent-net-generator.rules:

# ignore VirtualBox virtual interfaces
ATTR{address}=="08:00:27:*", GOTO="persistent_net_generator_end"

I've also removed any rules in /etc/udev/rules.d/70-persistent-net.rules. Sadly, it doesn't seem to help. Neither does changing the MAC address or switching to a different virtual network adapter.

The problems only occur for the clone, not for the original machine.

[maddes.b]

Fixing the rule is only 50% of the solution. Did you delete /etc/udev/rules.d/z25_persistent-net.rules? Or at least removed the definitions from the original machine?

Then the next clone will be working.

[Nick Henry]

Replying to Mathiasdm:

I have pretty much the same problem, running an Ubuntu 8.04 (Hardy) 32-bit guest on an Ubuntu 8.10 64-bit host (see also ​http://forums.virtualbox.org/viewtopic.php?t=12060 ).

I've added the following to /etc/udev/rules.d/75-persistent-net-generator.rules:

# ignore VirtualBox virtual interfaces
ATTR{address}=="08:00:27:*", GOTO="persistent_net_generator_end"

I've also removed any rules in /etc/udev/rules.d/70-persistent-net.rules. Sadly, it doesn't seem to help. Neither does changing the MAC address or switching to a different virtual network adapter.

The problems only occur for the clone, not for the original machine.

Mathiasdm, here is what I had to do to get my Ubuntu 8.04 (Hardy) Virtual Machine working again:

open the persistent-net-generator.rules file

vim /etc/udev/rules.d/75-persistent-net-generator.rules

search for the "# ignore _ virtual interfaces" line

/^# ignore .* virtual interfaces$

directly below this comment there will be a command, AFTER THE COMMAND, add the following lines

# ignore VirtualBox virtual interfaces
ATTR{address}=="08:00:27:*", GOTO="persistent_net_generator_end"

save and close the persistent-net-generator.rules file

remove the persistent-net.rules file

rm -f /etc/udev/rules.d/70-persistent-net.rules

reboot the server (or you may also want to shutdown and take a snapshot)

[Klaus Espenlaub]

This is not a bug in VirtualBox, this is intentional debian/ubuntu behavior.