Nate Bargmann <n...@n0nb.us> wrote: > After I thought about it some, there is a certain logic to udev's > behavior but it would seem to make more sense if the network adapter is > on a hot-pluggable interface (PCMCIA, USB, etc.), or is in addition to > the adapter already assigned to eth0 on a PCI bus. The behavior of > assigning eth1 to a new adapter on a PCI bus where the old adapter no > longer is present
Unfortunately, absent the "admin mind reading" kernel module, I doubt this can ever be solved for everyone. For me, the standard udev way of doing it works - it's simple enough, and easily enough managed as long as you remember to edit the file when you change hardware. I have "unfond" memories of working with a box in the past where the interfaces came up in seemingly (to inexperienced me) random order such that I'd be using eth0 during install, then when I booted the installed system I found eth0 didn't work and I should now be using eth1 - but if I booted from the CD for maintenance (I learned a lot from breaking things !) then they'd swap back again. Clearly this doesn't suit everyone - and as things stand now (or at least, sans-systemd) it's fairly easy to fix things up yourself (eg don't use udev and sort out module loading order yourself). But as I see it, sorting out one entry in udev rules is simple enough. Anyone who thinks that changing the interface name in a hard manner, such that you have to find and edit every place you used it - network config, firewall config, utility scripts you've written, data logging scripts you've written, ... - is a complete and utter clueless numpty. Oh, that's exactly what systemd and the new udev forces you to do. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
