While it helps in a pragmatic kind of way, carving out exemptions is really a kludge.
The issue is that both aspects of the issue are valid. Persistence is important in many situations but in others, it's more important to not have things changing when they don't need to be changing. Arguably, there are many more installations that will only be needing one network card, called eth0 than not but... At first I thought that the obvious answer is to make this configurable. Obviously, it is in a "You can edit the files" kind of way but perhaps an install option "Use persistent nic labelling y/n" would be the way to go. Then I thought some more. The real issue is expecting nic labeling to be more than a convenience. There is zero reason to expect eth0 to mean anything. It's not the persistent coding that's at issue, it's the scripts further down the process that are broken. Assigning 192.168.0.5 to eth0 or setting it DHCP? Wrong! The default action should be the scripts to determine the interface based on rules. Probably by "first available interface" for most set-ups and probably by mac address where more complex set-ups are involved. That's my take on it anyway. Obviously I think more discussion is warranted. If anyone knows of one ongoing, I'd appreciate a link. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/341006 Title: ease cloning of virtual images by disabling mac address rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/341006/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
