/etc/udev/rules.d/70-persistent-net.rules not automatically generated

Bug #802538 reported by ben thielsen on 2011-06-27
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Medium
Unassigned

Bug Description

previous to 11.04, if /etc/udev/rules.d/70-persistent-net.rules was deleted, it would be automatically regenerated at boot. this appears to now not be happening.

if run manually, write_net_rules complains "missing valid match" - although i don't know if this is necesarily meaningful.

i did find this debian bug, which appears to maybe be similar/related [although it's a bit old at 2008]:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492193

1] 11.04

2] udev:
        Installed: 167-0ubuntu3
        Candidate: 167-0ubuntu3
        Version table:
      *** 167-0ubuntu3 0
              500 /http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
              100 /var/lib/dpkg/status

3] i expected /etc/udev/rules.d/70-persistent-net.rules to be automatically created by the system
4] it was not
---
Architecture: amd64
CurrentDmesg: [ 21.320072] eth0: no IPv6 routers present
DistroRelease: Ubuntu 11.04
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: VMware, Inc. VMware Virtual Platform
Package: udev 167-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-server root=/dev/mapper/vg_1-root ro
ProcVersionSignature: Ubuntu 2.6.38-8.42-server 2.6.38.2
Tags: natty
Uname: Linux 2.6.38-8-server x86_64
UpgradeStatus: Upgraded to natty on 2011-05-02 (56 days ago)
UserGroups:

dmi.bios.date: 09/22/2009
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd09/22/2009:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.

Serge Hallyn (serge-hallyn) wrote :

Thanks for taking the time to report this bug.

I couldn't reproduce this on natty. What sort of environment do you have? Could you run 'apport-collect 802538'?

Changed in udev (Ubuntu):
status: New → Incomplete

apport information

tags: added: apport-collected natty
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Serge Hallyn (serge-hallyn) wrote :

(Note the fix for the debian bug, if I read it right, is still in the natty udev source)

Changed in udev (Ubuntu):
status: Incomplete → New
Serge Hallyn (serge-hallyn) wrote :

Ah, the bootdmesg shows that eth0 is mac '00:50:56*', which is a VMWare NIC. For some reason, extras/rule_generator/75-persistent-net-generator.rules filters out that NIC. It didn't use to in lucid, but does in both debian sid and in ubuntu natty.

I don't know exactly what the reason for this is, so marking this confirmed so a udev pro can answer whether it's meant to be like this.

Ben, you should be able to work around this by editing /lib/udev/rules.d/75-persistent-net-generator.rules and commenting out line 35, which reads:

ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"

Changed in udev (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
ben thielsen (btb-bitrate) wrote :

thanks for finding that. indeed, if i comment that out as you suggest, 70-persistent-net.rules is automatically generated by the system. perhaps this was meant to address situations in which the os is a vmware host? obviously when the os is a vmware guest, this result in undesirable consequences.

ben thielsen (btb-bitrate) wrote :

to add a bit of detail here - this is a vmware esx 4 environment, with a number of hosts providing a number of guests, with the "typical" characteristics of this sort of environment [shared storage from a san array, vmotion, etc. etc.]. in this particular scenario, a minimal ubuntu server install is used as a vm template. it's maintained and kept up to date, and new guests are deployed from the template. when a new guest is deployed, a new mac address is generated and subsequently there is then a discrepancy between the actual mac address of the new system, and the data in 70-persistent-net.rules. it hasn't been a huge deal, as there are a handful of various tasks associated with preparing/deploying the template [generate new ssh keys, set new unique hostname, etc] within which i've included simply deleting 70-persistent-net.rules.

this has worked quite well up until 11.04. the newly deployed guest would boot, and a new 70-persistent-net.rules file would be automatically be generated, with the correct mac address.

so the question i have is why is this filter here? what condition is it intended to address? was there a previous bug with which this filter was added?

JaSauders (jasauders) wrote :

I'd like to confirm I just ran into this on Ubuntu 11.10 64 bit. I was trying to troubleshoot why both of my NICs did not appear in the 70-persistent-net.rules file, as only one of them appeared. I deleted it thinking on reboot it would re-generate, and it did, about two times. I kept deleting it while making changes to my network interface file for my static IP assignment. At one point, it stopped re-generating. A fellow Linux user linked me to this bug and I commented out line 35 as notated above, and sure enough it re-generated.

Francesco Pretto (ceztko) wrote :

This is a case where satysfying a wish cause problems to others.
In my opinion the rule should be this:

at every boot there's a check on every 70-persistent-net.rules entry:

if (MAC(entry) is kvm/qemu/wmware type
        && the entry was referred to a card card in the PCI bus (read: not used often for hotpluggable devices)
        && MAC(entry) doens't exist anymore)
    delete(entry);

Just disabling persistent net generator is, in my opinion, against the purpose of udev and it's causing troubles to users that liked the behavior of seeing the 70-persistent-net.rule to be autogenerated on delete.
But I think udev is powerful enough that we can find a solution that satisfy "everybody".

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers