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