| Summary: | >=sys-fs/udev-197: predictable network interface names are not persistent | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ilya Lebedev <ilya> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ilya Lebedev
2013-05-27 14:55:03 UTC
correct, if you add/remove instead of plain replace it's likely the ordering changes as the machine (bios) sees the configuration different (which is predictable ;-) http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n22 if you plan to add/remove instead of replacing the said device often, for whatever reason, you propably want to go with the MAC based enx* names or custom MAC based rules instead Then what is the reason to use "predictable names" if they destroy everything? :) For what reason http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames states that add/remove hardware is safe - "NO RE-ENUMERATION TAKES PLACE"? === Come again, what good does this do? With this new scheme you now get: Stable interface names across reboots Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place ==== And how does it come that GEOGRAPHICAL location of the other cards is changed by adding a new one? |