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
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
