On 02/24/2017 10:10 AM, Harald Dunkel wrote: > On 02/23/2017 04:25 PM, Christian Seiler wrote: >> >> There's a policy which are going to be preferred. man 5 systemd.link >> tells you what the options are and /lib/systemd/network/99-default.link >> tells you what the default setting is (the first successful one is >> used). > > Of course I stumbled over this one: > > % man 5 systemd.link > No manual entry for systemd.link in section 5 > > Now I got confused: Who is responsible for renaming the NIC names? > Is this a systemd feature, is this the job of udev, or are the NICs > renamed by the kernel very early at boot time? Shouldn't I get the > same predictable name for eth0, no matter what?
udev is responsible. The kernel drivers give the NIC a name initially, and they can mark that name as being "persistent" or not. The vast majority of drivers do not mark the name as being persistent. The names the kernel returns will typically be something like eth0, etc. udev will then rename the device once it encounters it. In newer udev versions, it will use some (but not all) settings from systemd.link files. The other settings are interpreted by systemd.networkd. (And if you don't use that or don't have that installed, they will be ignored.) That's also the reasnon why those files are in a systemd directory, even though udev interprets some parts of them - since the matching of interfaces is identical for the purposes of udev and systemd-networkd, systemd developers decided it would be simpler to have just one configuration file that is read by both. (udev and systemd are both in the same repository, even though you can use udev without systemd.) >> On my Stretch system that is: >> >> NamePolicy=kernel database onboard slot path >> > > AFAIU > NamePolicy=kernel > > makes sure that net.ifnames=0 given on the kernel command line > works. Is this correct? No. net.ifnames=0 will have udev completely ignore NamePolicy here and not rename the interface at all. NamePolicy=kernel will most likely never trigger on any system you have (it has never triggered on any system I have), it's for the case where the kernel driver says "yeah, the name I chose is already a name that's going to be persistent". This will never be interfaces like eth0, etc. I suspect this is mostly for SoC-type devices which have one onboard network interface that's fixed and thus will always have the same name. >> 'kernel' and 'database' are likely going to fail in most cases (kernel >> means the kernel indicates that the name used so far is already >> predictable, which it only does for very special hardware, probably >> embedded or similar, and database means that there's an entry in the >> udev hardware database, which you'd have to do manually, because I >> don't know of any upstream rules), so basically it's the following >> logic: >> >> - first try ID_NET_NAME_ONBOARD >> - if that doesn't exist, try ID_NET_NAME_SLOT >> - if that doesn't exist, try ID_NET_NAME_PATH >> > Not to forget > > - if that doesn't exist, use INTERFACE >From the code logic, sure, but you'll be hard-pressed to find an interface that doesn't have ID_NET_NAME_PATH set. ;-) Regards, Christian
