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

[JB]

On 6/2/2016 10:20 AM, Greg KH wrote:
> On Thu, Jun 02, 2016 at 10:14:22AM -0600, JB wrote:
>> 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.
> Ok, but please ask on a fedora list as this is a fedora specific issue,
> as it is running a very old version of systemd as well as the kernel, so
> there's not much we can do here either.
I doubt that it's fedora only, it looks deeper than that to me, but I 
will check and if not, perhaps prove the issue out on either another 
distro or a custom build.
>
>>> 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!
> You might try the real-time kernel patches, they seem to perform just as
> well, if not better, than RTAI, and you are not stuck with obsolete and
> unsuportable kernel versions.
>
Thanks, that's the plan but in order to buy myself that time, I'd need 
to get this resolved first.