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

Bug #802538 reported by ben thielsen
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Confirmed
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.

Revision history for this message
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
Revision history for this message
ben thielsen (btb-bitrate) wrote : BootDmesg.txt

apport information

tags: added: apport-collected natty
description: updated
Revision history for this message
ben thielsen (btb-bitrate) wrote : Dependencies.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : Lspci.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : ProcInterrupts.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : ProcModules.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : UdevDb.txt

apport information

Revision history for this message
ben thielsen (btb-bitrate) wrote : UdevLog.txt

apport information

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
Matthew M. Boedicker (matthewm-boedicker) wrote :
Revision history for this message
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.

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.