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

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'?

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

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

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"

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.

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?

See https://bugs.launchpad.net/ubuntu/+source/udev/+bug/341006

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.

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