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: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | 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 12:52:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
*** This bug has been marked as a duplicate of bug 896135 *** |
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?