Bug 904678

Summary: systemd completely breaks on an upgrade to Fedora 18 machines with multiple network interfaces
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-28 07:52:05 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Michal Jaegermann 2013-01-26 19:59:08 EST
Description of problem:

After an upgrade to Fedora 18 of a working machine with two network interfaces one is greeted with a missing network connection.  It turns out they names of network interfaces are swapped at random from boot to boot with no way to predict an outcome.  That despite of a pre-existing file

/etc/udev/rules.d/70-persistent-net.rules

which specifies names tied to MACs

Version-Release number of selected component (if applicable):
systemd-197-1.fc18.1.x86_64

Expected results:
A control over how network devices are named (or at least a consistency
over reboots)

Additional info:
If devices happen to have different drivers, which are also modules, then an old hack of forcing in a modproble configuration a load order ('softdep' directive can be used for that) seems to work around.  It seemed to me that years ago it was possible to forget about such bogosity.

Do not try to tell me that NM facing DHCP server can handle this breakage.  This is true but so what?
Comment 1 Michal Schmidt 2013-01-28 07:52:05 EST

*** This bug has been marked as a duplicate of bug 896135 ***