[systemd-devel] systemd network interface names - new twist

[JB]

Hi Greg,
Thank you very much for responding!

On 6/2/2016 9:46 AM, Greg KH wrote:
> On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote:
>> I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd. The
>> motherboard is an intel board with dual onboard NIC. I installed FC21
>> initially with secondary ethernet interface disabled in the BIOS. Then after
>> install, I enabled it. However, while the first NIC name comes up as
>> expected getting renamed from eth0 to eno#. The second NIC never gets
>> renamed and instead is brought up as eth1.
>>
>> What's up with that? I thought they were all supposed to get en* names. I
>> mean after all, I've already retooled all our software to accommodate the
>> new scheme.
> This sounds like a Fedora bug, in noticing your "new" NIC that showed up
> after the system was installed.  I suggest you file a bug with their
> reporting system.
Sorry, I probably should have been more clear. I disabled the secondary 
NIC in the BIOS intentionally prior to OS installation. Then I did the 
FC21 minimal installation which excludes most of Fedora's network 
management stuff. I also disabled NetworkManager and ripped out any 
other fedora specific stuff. In looking at dmesg and journalctl I'm 
seeing where systemd renames eth0 to it's new name, but leaves eth1 
untouched which is the part that is confusing me.

The new NIC showed up, as expected, after I enabled it in the BIOS. I 
think I could more easily see your point if NIC naming was determined at 
OS installation time but my experience has been that systemd does it as 
part of it's initialization regardless of what was there when the OS was 
installed.
>
> Also, please note that the 3.18 kernel is very old and unsupported, you
> might want to update to a modern kernel release :)

Yeah, I'm aware of that. Sadly, the application I'm dealing with has 
strong dependencies on RTAI and the most recent kernel supported by even 
the most recent beta of RTAI is 3.18.22 :( This is particularly 
challenging since most of the driver support we need is all in the newer 
kernels. I've been looking at some of the more recent RT processing 
capabilities slowly making their way into the stock kernel but for now, 
it's a circumstance I must contend with!

Thanks,
JB