[svlug] Inits (was: On the process of picking up systemd)

Rick Moen rick at svlug.org
Sat Jan 17 11:33:12 PST 2015


Akkana Peck wrote:

> Multiple network cards. For instance, try booting a laptop that
> has built-in wi-fi but also a USB wi-fi dongle; or try plugging in
> two different USB wi-fi dongles. But -- here's the kicker -- first
> remove the udev entries that most modern distros add as workarounds
> to get around the indeterminacy. For instance, on Debian, remove
> both of these files:
> 
> /etc/udev/rules.d/70-persistent-net.rules
> /lib/udev/rules.d/75-persistent-net-generator.rules 

This was the plumbing I was mentioning to Steve Litt upthread in
http://lists.svlug.org/archives/svlug/2015-January/060174.html, a couple of
days ago.

At the time, I said that /etc/udev/rules.d/70-persistent-net.rules is
'obviously intended to ensure that a specified MAC address always ends up as
eth0' on the described system.  That file says:

# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:aa:b2:05", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

However, shortly after posting that, I realised that it's not quite that
simple.  The cited plumbing appears to say to udev 'Any time you receive a
uevent from the kernel letting you know that the kernel heard from the PCI
controller chip that MAC address 08:00:27:aa:b2:05 has been spotted, create
add an eth0 special-file node to /sys/class' -- or something like that.[1]

That having been said, I'm still not sure how that ensures that the kernel 
addresses the device as eth0.  Do you happen to know, Akkana?  I really
don't.

I've been tempted to deliberately lose udevd and /sys from server builds on
a theory of 'this looks like avoidable complexity not needed in my usage
scenario', but I'd like to figure out in advance what if anything would ever
break and under what conditions.


> I'm sure there are other, thornier problems where a dependency-based init
> really is the best fix.

Quibble:  I think you mean event-based, here (rather than dependency-based).

Dependencies _have_ worked their way into old-school inits for a long time,
and (for example) the Debian/Ubuntu implementation of SysVInit because of
its insserv modification.[2]  There are scope limitations to what can be
accomplished with a sequential-type init even with dependency-handling
modifications such as insserv, which reorders symlinks in /etc/rc?.d/ based
on dependencies specified by LSB headers in the init.d scripts themselves.
As https://wiki.debian.org/Debate/initsystem/upstart says about insserv:
'This is very much a bolt-on, and only handles dependencies at boot/shutdown
time (i.e., during runlevel changes) and can't handle any complicated
service interdependencies at runtime.'

So, sequential-type inits often _do_ handle dependencies, just not in a fully
dynamic fashion that is able to respond on arbitrary occasions during
runtime to, for example, a user plugging in a new USB-connected printer or
storage device.

(Me, I'm happy with just looking in /var/log/messages to see what device it
is this time and act accordingly, but the desktop-Linux set expects more
automagic than that.)


[1] In case people never noticed this before, eth* devices don't exist in
/dev, unlike -- say -- sda, sda1, tty0, ttyS0, etc.

[2] https://packages.debian.org/sid/insserv



More information about the svlug mailing list