On 05/27/2016 08:36 AM, Lennart Poettering wrote:
On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote:
So I've been playing with this a bit, but I've run into another snag. It
seems that on initial boot even with "net.ifnames=0" the ethernet interface
ordering isn't consistent.
This means that two systems with identical hardware can end up mapping
"eth1000" to different physical slots. This makes it very difficult to set
up multiple machines.
Yupp, thta's what we have been saying all along: enumerating and
probing devices is not stable, that's why the predictable interface
names have been introduced after all, so that the same name refers to
the same device all the time.
I assume this is due to parallel network device initialization from
udev?
Well, udev just modprobes the driver. The driver then probes all
devices and that happens in any order it likes.
Looking at the kernel code, the probing order for pci NICs for a given driver is
pretty well deterministic. From what I can tell, the problems happen when we
modprobe another driver before the previous one is finished walking the bus.
When this happens you can get sequential device numbers being assigned to one
driver, then the other, then back to the first.
Is there a way to serialize this at the cost of slower system
initialization? I don't really care what the ordering is, as long as it is
consistent on identical hardware.
(Yes, I realize that the ideal would be to use the newer position-based
naming, but that would mean a whole lot more work at this point.)
Well, the old scheme is borked, that's why we fixed it. You don't like
the fix, but want it fixed anyway. Not sure what else we can suggest...
The reason why I'm poking at this is that the old scheme worked "good enough"
for us for several years. Now of course the new scheme is better, but it breaks
backwards compatibility. This makes it difficult to automatically upgrade an
existing system to an OS using the new scheme since all the names would change.
(And we've got the old interfaces stored in databases and such in our
management software.)
And the annoying thing is that if I turn off the new naming scheme there seems
to be less determinism than there used to be. I assume this is due to the
effort to extract more parallelism at boot, but it's causing me grief.
Anyways, I think I understand enough about what's going on to try and figure out
a workaround until we can move to the new naming scheme.
Thanks for the help,
Chris
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
