Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688920 - Leapp Upgrade Of RHEL 7.6 To 8 Beta Causes Network Connection Name Change.
Summary: Leapp Upgrade Of RHEL 7.6 To 8 Beta Causes Network Connection Name Change.
Keywords:
Status: CLOSED DUPLICATE of bug 1668194
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: leapp-repository
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Leapp team
QA Contact: Alois Mahdal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-14 17:50 UTC by Bernie Hoefer
Modified: 2019-03-15 13:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-15 13:00:06 UTC
Target Upstream Version:


Attachments (Terms of Use)
SOSreport from before the leapp upgrade. (deleted)
2019-03-14 17:58 UTC, Bernie Hoefer
no flags Details
SOSreport from after leapp upgrade. (Network broken.) (deleted)
2019-03-14 17:59 UTC, Bernie Hoefer
no flags Details
Gzip'ed tarball of /tmp/download-debugdata, /var/log/upgrade.log and /var/lib/leapp/leapp.db. (deleted)
2019-03-14 18:00 UTC, Bernie Hoefer
no flags Details

Description Bernie Hoefer 2019-03-14 17:50:14 UTC
Description of problem:
Using this RHEL8 High Touch Beta lab manual:

  Lab Manual: Migrating your deployment to Red Hat Enterprise Linux 8
  <https://access.redhat.com/groups/3614781/announcements/3746941>

I tested the leapp upgrade of RHEL 7.6 --> 8.0 beta on a KVM/QEMU virtual machine.  RHEL 7.6 was installed from the DVD ISO image.  During the install, I:

+ accepted the default "Software Selection" of a minimal installation,
+ Clicked the "Network & Host Name" item:
  + entered a FQDN in the host name field and
  + noticed the installer had detected my virtual machine's
    "Ethernet (eth0)" interface
  + toggled the on/off switch to enable that interface and saw that
    it received a QEMU NAT address.
  + under that same item, noticed the installer had detected my virtual
    machine's "Ethernet (eth0)" interface; I toggled the on/off switch to
    enable it and saw that it received a libvirt NAT address.

This resulted in a working RHEL 7.6 virtual machine whose network interface was "eth0":

[root@rhel76-80-20190314 ~]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
eth0             UP             52:54:00:35:6e:15 <BROADCAST,MULTICAST,UP,LOWER_UP>

[root@rhel76-80-20190314 ~]# ip -br -4 addr
lo               UNKNOWN        127.0.0.1/8 
eth0             UP             192.168.122.126/24

After executing the procedures, I ended up with a RHEL8 virtual machine whose networking had failed to start.  Upon investigation, I found that the upgrade process had changed my connection name:

[root@rhel76-80-20190314 ~]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
ens3             UP             52:54:00:35:6e:15 <BROADCAST,MULTICAST,UP,LOWER_UP>

...and because of that, the eth0 connection could not be brought up.

This was easily solved by:

1. Editing /etc/sysconfig/network-scripts/ifcfg-eth0, changing the
   'NAME="eth0"' and 'DEVICE="eth0"' lines to "ens3",
2. moving /etc/sysconfig/network-scripts/ifcfg-eth0 to
   /etc/sysconfig/network-scripts/ifcfg-ens3, and
3. Executing "nmcli conn reload".  (That brought the device &
   connection up with the correct values.)


Version-Release number of selected component (if applicable):
leapp-0.5.0-1.el7_6.noarch.rpm



Steps to Reproduce:
1. Stand up RHEL 7.6 virtual machine in plain QEMU/KVM
   virtualization environment per above description.
2. Follow the steps in the RHEL8 High Touch Beta lab manual.



Actual results:
RHEL8 beta virtual machine with non-working network.



Expected results:
RHEL8 beta virtual machine with working network.



Additional info:
Don't know if this matters, but I'm using Fedora 28 for my QEMU/KVM platform.  Here are the exact packages I'm using:

$ rpm -qa | grep -iE kvm\|libvirt\|qemu | sort
ipxe-roms-qemu-20170710-3.git0600d3ae.fc28.noarch
libvirt-bash-completion-4.1.0-5.fc28.x86_64
libvirt-client-4.1.0-5.fc28.x86_64
libvirt-daemon-4.1.0-5.fc28.x86_64
libvirt-daemon-config-network-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-interface-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-network-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-nodedev-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-nwfilter-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-qemu-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-secret-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-core-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-disk-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-gluster-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-iscsi-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-logical-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-mpath-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-rbd-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-scsi-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-sheepdog-4.1.0-5.fc28.x86_64
libvirt-daemon-driver-storage-zfs-4.1.0-5.fc28.x86_64
libvirt-daemon-kvm-4.1.0-5.fc28.x86_64
libvirt-glib-1.0.0-5.fc28.x86_64
libvirt-libs-4.1.0-5.fc28.x86_64
python2-libvirt-4.1.0-1.fc28.x86_64
qemu-block-curl-2.11.2-4.fc28.x86_64
qemu-block-dmg-2.11.2-4.fc28.x86_64
qemu-block-gluster-2.11.2-4.fc28.x86_64
qemu-block-iscsi-2.11.2-4.fc28.x86_64
qemu-block-nfs-2.11.2-4.fc28.x86_64
qemu-block-rbd-2.11.2-4.fc28.x86_64
qemu-block-ssh-2.11.2-4.fc28.x86_64
qemu-common-2.11.2-4.fc28.x86_64
qemu-guest-agent-2.11.2-4.fc28.x86_64
qemu-img-2.11.2-4.fc28.x86_64
qemu-kvm-2.11.2-4.fc28.x86_64
qemu-system-x86-2.11.2-4.fc28.x86_64
qemu-system-x86-core-2.11.2-4.fc28.x86_64

Comment 2 Bernie Hoefer 2019-03-14 17:58:00 UTC
Created attachment 1544147 [details]
SOSreport from before the leapp upgrade.

Comment 3 Bernie Hoefer 2019-03-14 17:59:00 UTC
Created attachment 1544149 [details]
SOSreport from after leapp upgrade.  (Network broken.)

Comment 4 Bernie Hoefer 2019-03-14 18:00:13 UTC
Created attachment 1544150 [details]
Gzip'ed tarball of /tmp/download-debugdata, /var/log/upgrade.log and /var/lib/leapp/leapp.db.

Comment 5 pstodulk 2019-03-15 13:00:06 UTC
Hi. We have already BZs created for that:
  bug 1668194
  bug 1668192
  bug 1668260
  bug 1668249
  bug 1668257

I am closing the bug as duplicate. I havn't checked which of those bugs is specific to your case, but I guess that all of them will be resolved together.

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

Comment 6 Bernie Hoefer 2019-03-15 13:20:20 UTC
(In reply to pstodulk from comment #5)

> Hi. We have already BZs created for that:
>   bug 1668194

Thanks, Petr!  I had looked for already-open bugs before submitting this one, but I was too narrow in my search.  (I was searching against "Red Hat Enterprise Linux 7"'s "leap" component; I see BZ 1668194 is against "leapp-repository".)

Comment 7 pstodulk 2019-03-15 13:26:12 UTC
In short, almost everything you would like to report related to the upgrade will be related to the leapp-repository component. Leapp is the framework. When you find that something after the ugprade is not working or you expect different result, it is leapp-repository.


Note You need to log in before you can comment on or make changes to this bug.