| 1 |
On Tue, Dec 20, 2016 at 11:21 AM, Heiko Baums <lists@××××××××××××.de> wrote: |
| 2 |
> Am 20.12.2016 um 05:23 schrieb Andrej Rode: |
| 3 |
>> |
| 4 |
>> Yeah they make life easier. From your talk you never had a problem |
| 5 |
>> with eth<0,10> switching names after boot. Everyone who had them |
| 6 |
>> appreciates predictable network interfaces. |
| 7 |
> |
| 8 |
> Everyone who had them could learn how to write simple udev rules to |
| 9 |
> get fixed eth<0,10> names after every boot. No systemd and no |
| 10 |
> "predictable" names necessary. |
| 11 |
> |
| 12 |
> Nevertheless I'm still wondering what's so predictable at those |
| 13 |
> incomprehensible, cryptic device names anyway. And I don't want to |
| 14 |
> know that. |
| 15 |
|
| 16 |
The predictable interface names (the systemd developers have an |
| 17 |
unfortunate knack for misnaming ) arose for a multi-NIC world where |
| 18 |
|
| 19 |
1) the kernel's ethX name for a particular NIC can change from one |
| 20 |
boot to another |
| 21 |
|
| 22 |
2) udev renaming NICs "ethX" can break if you rename a NIC "eth4" and |
| 23 |
the kernel later names another NIC "eth4" as it enumerates the |
| 24 |
hardware. |
| 25 |
|
| 26 |
Given the above, the udev maintainers could've implemented a policy |
| 27 |
that a NIC couldn't be renamed "ethX" but they decided no longer to |
| 28 |
default to MAC-based naming rules and came up with naming based on |
| 29 |
whether a NIC is an on-board one (enoX), a PCI Express one (ensX), a |
| 30 |
PCI one (enpXsY), etc. In doing so, they defaulted to names that are |
| 31 |
more complex than the kernel's (ethX) but you can now replace a NIC |
| 32 |
without editing a file under "/etc/udev/rules.d/". |
Archives