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