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

[Greg KH]

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.

> > 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.

Best of luck!

greg k-h