Re: systemd: some more questions
On Fri, Feb 14, 2014 at 12:34 PM, Reco <recoverym4n@gmail.com> wrote:
> On Fri, 14 Feb 2014 17:42:54 +0100
> "Gian Uberto Lauri" <saint@eng.it> wrote:
>> Brian writes:
>>> On Fri 14 Feb 2014 at 14:11:30 +0100, Gian Uberto Lauri wrote:
>>>> Ralf Mardorf writes:
>>>>
>>>>> During setting up Arch Linux with systemd the device name switched from
>>>>> eth0 to enp3s0 on my machine.
>>>>
>>>> Any reason for this?
>>>
>>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>
>> Interesting. But may I ask a full identification (manufacturer, model
>> at least) of an system that showed the problem of having the
>> interfaces have not a stable name between reboots? I am _really_
>> curious to know of one of them.
>>
>> The ONLY time I have seen this was with a template VM. Each new vm
>> started from the base image had a different "hardware identification"
>> (MAC? - it was some years ago, can't remember the full details). that
>> changed eth0 to eth1, eth2... A quick fix to the udev scripts removed
>> the problem.
>
> Do you want to know a real reason? Ok:
>
> It all started with a 'biosdevname' package, originally written by Dell
> employee, which 'solved' old RedHat problem - network interfaces names
> were changing between reboots, UNLESS you've specified MAC addresses in
> the interface definition (/etc/sysconfig/network-scripts/if-eth*).
> Given the quality of so-called 'Dell servers' - heck, things like
> this did happen, are happening and will happen.
>
> Note, that it WAS solved in Debian, like, 10 years before that by udev
> rules generator, which put MAC address of the interface into an
> appropriate udev rule.
>
> Next, someone at RedHat looked at the mess which their
> 'network-scripts' became, and wrote NetworkManager. Unsure whoever came
> with the idea of using NetworkManager on a server - but RHEL6 does that
> out-of-the-box.
> Does NetworkManager use /etc/sysconfig/network-scripts? Of course, no,
> as it would violate the whole 'next-clicky-next-clicky' way to 'manage
> the network'. So, another hack was needed, and 'biosdevname' was
> choosed as such.
>
> So, then systemd was written - they merely scratched old RedHat itch,
> no more. They didn't make it work first, so they patched udev (which
> conveniently is in the same source tree as systemd is), which yielded
> poor RedHat customers so called 'unpredictable predictable network
> interface names'.
>
> Good thing is Debian maintainers reverted this ugly hack for Debian
> packages.
It has nothing to do with Red Hat's ifcfg network scripts or with
network Manager.
And it has nothing to do with Red Hat not having the udev net rules
generator - you can look at old Fedora releases or current or old RHEL
or RHEL clone releases.
One known problem with the udev net rules generator is that, if you
replace your unique card eth0, the new card will be called eth1 if you
don't remember to delete the "/etc/udev/rules.d/" rule that the udev
net rules generator has created.
So the problem that the new behavior of udev solves is that cards are
named according to their hardware slot/placement/...
There are drawbacks to (almost) everything: the new behavior makes us
have to put with weird and unfamiliar nic names.
As I posted earlier, there's a kernel cmdline option to enable/disable
this behavior.
Reply to: