Bug 1659137

Summary: ReaR doesn't restore the network configuration when custom interface naming is used
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: rearAssignee: Pavel Cahyna <pcahyna>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: medium Docs Contact:
Priority: urgent    
Version: 7.6CC: bwelterl, djez, fkrska, jkucera, ovasik, pcahyna, rmetrich
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1663222 1663418 (view as bug list) Environment:
Last Closed: 2019-08-06 13:12: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:
Bug Depends On:    
Bug Blocks: 1663222, 1663418    

Description Renaud Métrich 2018-12-13 16:35:12 UTC
Description of problem:

When a network interface is not standard (e.g. "ethX", "ensX", etc) but customized (e.g. "my-eth"), ReaR doesn't set up the network interface and this ends up having no network, which is an issue unless DHCP is used.

Version-Release number of selected component (if applicable):

rear-2.4-2.el7.x86_64


How reproducible:

Always


Steps to Reproduce:
1. Set up a system and rename the interface

# cat /etc/sysconfig/network-scripts/ifcfg-first
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV6INIT="no"
DEVICE="first"
HWADDR="52:54:00:eb:6c:bf"
ONBOOT="yes"

2. Backup the system ("mkrescue" is enough) after configuring ReaR with USE_STATIC_NETWORKING=y

# cat /etc/rear/site.conf
USE_STATIC_NETWORKING=y


3. Try restoring the system


Actual results:

No network interface


Expected results:

Network interface configured


Additional info:

Upstream PR: https://github.com/rear/rear/pull/2004

Comment 2 Pavel Cahyna 2018-12-13 16:54:40 UTC
(In reply to Renaud Métrich from comment #0)

> Steps to Reproduce:
> 1. Set up a system and rename the interface
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-first
> TYPE="Ethernet"
> BOOTPROTO="dhcp"
> DEFROUTE="yes"
> IPV6INIT="no"
> DEVICE="first"
> HWADDR="52:54:00:eb:6c:bf"
> ONBOOT="yes"

Does this actually rename the interface? I would expect it to create a profile named "first" which still refers to the original interface (eth0 or whatever).

Comment 3 Renaud Métrich 2018-12-14 08:29:07 UTC
# ls -l /sys/class/net/
total 0
lrwxrwxrwx. 1 root root 0 Dec 14 09:12 first -> ../../devices/pci0000:00/0000:00:03.0/virtio0/net/first
lrwxrwxrwx. 1 root root 0 Dec 14 09:12 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx. 1 root root 0 Dec 14 09:12 second -> ../../devices/pci0000:00/0000:00:04.0/virtio1/net/second

Comment 13 Pavel Cahyna 2019-02-24 18:24:02 UTC
(In reply to Renaud Métrich from comment #0)
> 1. Set up a system and rename the interface
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-first
> TYPE="Ethernet"
> BOOTPROTO="dhcp"
> DEFROUTE="yes"
> IPV6INIT="no"
> DEVICE="first"
> HWADDR="52:54:00:eb:6c:bf"
> ONBOOT="yes"
> 
> 
> 3. Try restoring the system
> 
> 
> Actual results:
> 
> No network interface
> 
> 
> Expected results:
> 
> Network interface configured

Renaud,

should one expect the interface configured to be properly named ("first") or to have the original name ("eth0" or whatever)? When we try this, we get a proper IP address configured on the interface, but it is not renamed properly.

Comment 14 Renaud Métrich 2019-02-26 12:38:10 UTC
Interface will not be renamed, hence "eth0" is expected, but you shouldn't get any IP address if /etc/rear/local.conf contains "USE_STATIC_NETWORKING=y"

With the fix and USE_STATIC_NETWORKING=y, /etc/scripts/system-setup.d/60-network-devices.sh 's content gets renamed from "first" to "ethX"

Comment 15 Pavel Cahyna 2019-02-26 13:04:53 UTC
(In reply to Renaud Métrich from comment #14)
> Interface will not be renamed, hence "eth0" is expected, but you shouldn't
> get any IP address if /etc/rear/local.conf contains "USE_STATIC_NETWORKING=y"

It was meant "before the fix, you shouldn't get any IP address". After the fix you should of course.

Comment 19 errata-xmlrpc 2019-08-06 13:12:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2273