[systemd-devel] Proposal: integrate biosdevname into systemd tree

[Alexander E. Patrakov]

[Yes I know that this mail is several months too late, but better late
then never. Also it is too verbose.]

As of systemd-189, the persistent rule generators for network cards
were removed. They did serve a purpose - they prevented the multiple
network cards from being randomly renumbered during every boot due to
bus scanning and module loading being performed in parallel
threads/processes (i.e. modules were loaded in unpredictable order).

The removal of these rules also did serve a purpose - the approach
with renumbering within the eth* namespace never worked reliably, and
I had a chance to see the bug on a system belonging to my company.
Namely, we made a decision to rent a dedicated Dell server from a
hosting company and asked them to install Debian Stable on it. As both
onboard network cards required bnx2 firmware and thus were not
supported by Debian installer, the engineer installed an Intel network
card and performed a network-based installation through it, followed
by installation of the required firmware. Thus, the recorded
persistent state was: eth0 = Intel card, eth1 and eth2 = onboard
cards. Then he reconfigured the system to use eth1 for the internet
connection, connected eth2 to the same switch (but left it
unconfigured) and removed the Intel card. I.e., after this operation,
the system was supposed to have no eth0 at all, use eth1 (the first
onboard card) for internet connection, and leave eth2 (the second
network card) unused. Most of the time, the system correctly tried to
use its first onboard card. But during some boots, it somehow failed
to renumber the cards, had eth0 pointing to the first onboard card and
eth1 to the second one (despite having the rules with the correct
state), and thus used the second card, which became an issue when the
hoster configured MAC filtering on their switch. Thankfully, the issue
has been debugged.

What worries me now is that I was able to learn about the recommended
replacement (biosdevname) only via IRC, from Kay Sievers. There are no
pointers to biosdevname in any documentation that comes with
systemd-196. How are distributions supposed to learn that they have to
install it by default? And some of them don't learn. Here are some
examples from rolling-release or beta distributions:

Gentoo: in their ebuild for the original udev (that is built form
systemd tarball), added a post-installation message referencing
https://bugs.gentoo.org/show_bug.cgi?id=433746#c1 (note that they
themselves got the information from IRC). In their eudev fork,
restored the persistent rule generator in the original problematic
form that shuffles cards within the eth* namespace. It is possible to
install biosdevname manually, but the interface names need to be
adjusted after that, also manually.

Debian Testing: still defaults to the old unreliable rule generator.
OTOH, they are in deep freeze and thus all non-trivial bugs are
frozen, too. Same situation as with Gentoo WRT biosdevname.

LFS/BLFS: restored the generator as a part of their extra tarball
http://anduin.linuxfromscratch.org/sources/other/udev-lfs-196-4.tar.bz2
, does not offer biosdevname in either of the books.

Arch: rule generator not installed, biosdevname exists only in AUR -
i.e. the original problem that the rule generator attempted to solve
has just returned without any solution.

Mageia 3 beta1: rule generator not installed, biosdevname not
installed by default either, but possible to install manually.

For me, that counts as a serious FAIL in communications regarding the
change. Still, there is a way out.

First, maintainers of the distro packages usually read build logs. Why
not, as a very minimum, check for biosdevname existence at udev
configure time and print a warning if it is not found? A special
linked page on freedesktop.org (like it is the case with separate
/usr) would also be nice, with the description of the problem, the
attempted past solution with the rule generator, the problems with it
and the recommended replacements (biosdevname for servers or
name-agnostic configuration tools like NetworkManager for desktops).

Second, the old solution was written with the goal of working out of
the box. I.e. there was no work required from the distro maintainer to
integrate it. We can restore that by making biosdevname a part of
systemd git tree, as it is similar to the various *_id tools that
already come with systemd (note: I am not a developer of either
project and have not contacted biosdevname developers about the
proposed merge). What do you think about this idea?

-- 
Alexander E. Patrakov