Bug 1047246 - Kickstart unable to use additional network repositories; repos disabled with "repo needs an active network connection"
Summary: Kickstart unable to use additional network repositories; repos disabled with ...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-30 06:18 UTC by Georgi Georgiev
Modified: 2019-05-26 14:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-26 14:04:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
anaconda.log (5.06 KB, text/plain)
2014-01-08 03:24 UTC, Georgi Georgiev
no flags Details
ifcfg.log (16.06 KB, text/plain)
2014-01-08 03:24 UTC, Georgi Georgiev
no flags Details
syslog (76.53 KB, text/plain)
2014-01-08 03:24 UTC, Georgi Georgiev
no flags Details
packaging.log (23.93 KB, text/plain)
2014-01-08 03:25 UTC, Georgi Georgiev
no flags Details

Description Georgi Georgiev 2013-12-30 06:18:05 UTC
Description of problem:

Trying to perform an unattended install of RHEL7 Beta1, and the installation fails with warnings about missing packages, which should come from addition repositories defined in the kickstart file. After checking "packaging.log" we can see that the following message is printed for every repository:

05:13:45,854 ERR packaging: repo rhel-7-os.jnx needs an active network connection
05:13:45,862 ERR packaging: repo epel-7.jnx needs an active network connection

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

How reproducible: Every time.

Additional info:

Here is an excerpt illustrating the actual problem. You can see the error, and you can see that the "anaconda" repo is actually working fine and being hosted on the same server as the additional repos.
[anaconda root@localhost ~]# grep -e repo -e tree /tmp/packaging.log
06:09:45,089 DEBUG packaging: getting release version from tree at None (7.0)
06:10:21,290 INFO packaging: updating base repo
06:10:21,738 DEBUG packaging: getting release version from tree at None (7.0)
06:10:21,738 INFO packaging: configuring base repo
06:10:21,740 DEBUG packaging: getting release version from tree at http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ (7.0)
06:10:21,740 DEBUG packaging: retrieving treeinfo from http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ (proxy:  ; sslverify: True)
06:10:21,812 DEBUG packaging: adding yum repo anaconda with baseurl http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ and mirrorlist None
06:10:21,895 ERR packaging: repo rhel-7-os.jnx needs an active network connection
06:10:21,895 DEBUG packaging: disabling repo rhel-7-os.jnx
06:10:21,904 ERR packaging: repo epel-7.jnx needs an active network connection
06:10:21,905 DEBUG packaging: disabling repo epel-7.jnx
06:10:21,908 INFO packaging: gathering repo metadata
06:10:21,911 DEBUG packaging: getting repo metadata for anaconda
06:10:31,602 DEBUG packaging: writing repository file /tmp/yum.repos.d/anaconda.repo for repository anaconda
06:10:31,615 DEBUG packaging: getting release version from tree at None (7.0)
06:10:31,643 INFO packaging: gathering repo metadata
06:10:31,652 DEBUG packaging: getting repo metadata for anaconda
06:10:31,658 DEBUG packaging: installation yum config repos: anaconda

Here is how the network is configured in the kickstart:

[anaconda root@localhost ~]# cat /proc/cmdline 
method=http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ ksdevice=eth1 lang= bootdev=eth1 text ks=http://10.68.31.247/cblr/svc/op/ks/system/dcisys01 ip=eth1:dhcp kssendmac inst.sshd=1 

[anaconda root@localhost ~]# grep ^network /run/install/ks.cfg 
network --hostname dcisys01 --nodefroute --nodns --activate

(I tried this with only "network --hostname dcisys01" - same luck).

And here is the network actually working:

[anaconda root@localhost ~]# journalctl -b -l -a | grep eth
Dec 30 06:09:00 localhost kernel: Command line: method=http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ ksdevice=eth1 lang= bootdev=eth1 text ks=http://10.68.31.247/cblr/svc/op/ks/system/dcisys01 ip=eth1:dhcp kssendmac inst.sshd=1 
Dec 30 06:09:00 localhost kernel: Kernel command line: method=http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/ ksdevice=eth1 lang= bootdev=eth1 text ks=http://10.68.31.247/cblr/svc/op/ks/system/dcisys01 ip=eth1:dhcp kssendmac inst.sshd=1 
Dec 30 06:09:01 localhost dracut-cmdline[45]: Warning: 'method=' is deprecated. Using 'repo=http://10.68.31.247/cblr/ks_mirror/RHEL7b1-x86_64/' instead.
Dec 30 06:09:03 localhost dracut-initqueue[503]: Starting dhcp for interface eth1
Dec 30 06:09:03 localhost dhclient[554]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 (xid=0x448000d6)
Dec 30 06:09:04 localhost dhclient[554]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x448000d6)
Dec 30 06:09:29 localhost NetworkManager[1118]: Listening on LPF/eth0/52:54:00:c1:da:1c
Dec 30 06:09:29 localhost NetworkManager[1118]: Sending on   LPF/eth0/52:54:00:c1:da:1c
Dec 30 06:09:29 localhost NetworkManager[1118]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x4e97fd19)
Dec 30 06:09:29 localhost NetworkManager[1118]: Listening on LPF/eth2/52:54:00:7c:2c:03
Dec 30 06:09:29 localhost NetworkManager[1118]: Sending on   LPF/eth2/52:54:00:7c:2c:03
Dec 30 06:09:29 localhost NetworkManager[1118]: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 6 (xid=0x463143a)
Dec 30 06:09:29 localhost NetworkManager[1118]: Listening on LPF/eth3/52:54:00:7e:85:3f
Dec 30 06:09:29 localhost NetworkManager[1118]: Sending on   LPF/eth3/52:54:00:7e:85:3f
Dec 30 06:09:29 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 4 (xid=0x671a3c4e)
Dec 30 06:09:33 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 4 (xid=0x671a3c4e)
Dec 30 06:09:35 localhost NetworkManager[1118]: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 15 (xid=0x463143a)
Dec 30 06:09:37 localhost NetworkManager[1118]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x4e97fd19)
Dec 30 06:09:37 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 9 (xid=0x671a3c4e)
Dec 30 06:09:47 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 14 (xid=0x671a3c4e)
Dec 30 06:09:49 localhost NetworkManager[1118]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x4e97fd19)
Dec 30 06:09:50 localhost NetworkManager[1118]: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 13 (xid=0x463143a)
Dec 30 06:09:59 localhost NetworkManager[1118]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 (xid=0x4e97fd19)
Dec 30 06:10:01 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 12 (xid=0x671a3c4e)
Dec 30 06:10:03 localhost NetworkManager[1118]: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 10 (xid=0x463143a)
Dec 30 06:10:13 localhost NetworkManager[1118]: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 17 (xid=0x463143a)
Dec 30 06:10:13 localhost NetworkManager[1118]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 17 (xid=0x671a3c4e)

And here we can see that anaconda did understand that it needs to use eth1 for network connectivity:

[anaconda root@localhost ~]# grep eth /tmp/anaconda.log 
06:09:46,314 DEBUG anaconda: network: devices found ['eth0', 'eth1', 'eth2', 'eth3']
06:10:09,218 DEBUG anaconda: network: dumping ifcfg file for default autoconnection on eth0
06:10:11,186 DEBUG anaconda: network: setting autoconnect of eth0 to False
06:10:15,164 DEBUG anaconda: network: dumping ifcfg file for default autoconnection on eth2
06:10:15,248 DEBUG anaconda: network: setting autoconnect of eth2 to False
06:10:15,433 DEBUG anaconda: network: dumping ifcfg file for default autoconnection on eth3
06:10:15,496 DEBUG anaconda: network: setting autoconnect of eth3 to False
06:10:15,497 DEBUG anaconda: network: missing ifcfgs created for devices ['eth0', 'eth2', 'eth3']
06:10:15,564 INFO anaconda: unspecified network --device in kickstart, using eth1 (ksdevice boot parameter)
06:10:15,716 DEBUG anaconda: network: setting real kickstart ONBOOT value for devices ['eth1']

Comment 2 Radek Vykydal 2014-01-07 12:34:01 UTC
I am not able to reproduce the issue, can you please attach these log files:

/tmp/anaconda.log
/tmp/syslog
/tmp/packaging.log
/tmp/ifcfg.log

(the case with only "network --hostname dcisys01" in ks)

Comment 3 Georgi Georgiev 2014-01-08 03:24:07 UTC
Created attachment 846914 [details]
anaconda.log

Attaching anaconda.log as requested

Comment 4 Georgi Georgiev 2014-01-08 03:24:28 UTC
Created attachment 846915 [details]
ifcfg.log

Attaching ifcfg.log as requested.

Comment 5 Georgi Georgiev 2014-01-08 03:24:56 UTC
Created attachment 846916 [details]
syslog

Attaching syslog as requested.

Comment 6 Georgi Georgiev 2014-01-08 03:25:40 UTC
Created attachment 846917 [details]
packaging.log

Attaching packaging.log as requested.

Comment 7 Georgi Georgiev 2014-01-08 03:30:37 UTC
For the record, the IP address that DHCP assigned was 10.68.31.227, but it is not mentioned in any of these logs. here is what I see related to the network in /run/initramfs/, in case it helps:

[anaconda root@localhost ~]# grep -r -T . /run/initramfs/net.* 
/run/initramfs/net.bootdev     :eth1
/run/initramfs/net.eth1.dhcpopts       :new_broadcast_address=10.68.31.255
/run/initramfs/net.eth1.dhcpopts       :new_dhcp_lease_time=21600
/run/initramfs/net.eth1.dhcpopts       :new_dhcp_message_type=5
/run/initramfs/net.eth1.dhcpopts       :new_dhcp_server_identifier=10.68.24.48
/run/initramfs/net.eth1.dhcpopts       :new_domain_name=tk.japannext.co.jp
/run/initramfs/net.eth1.dhcpopts       :new_domain_name_servers='10.68.31.135 10.68.31.136'
/run/initramfs/net.eth1.dhcpopts       :new_expiry=1389172445
/run/initramfs/net.eth1.dhcpopts       :new_filename=/pxelinux.0
/run/initramfs/net.eth1.dhcpopts       :new_ip_address=10.68.31.227
/run/initramfs/net.eth1.dhcpopts       :new_network_number=10.68.30.0
/run/initramfs/net.eth1.dhcpopts       :new_next_server=10.68.31.247
/run/initramfs/net.eth1.dhcpopts       :new_subnet_mask=255.255.254.0
/run/initramfs/net.eth1.lease  :lease {
/run/initramfs/net.eth1.lease  :  interface "eth1";
/run/initramfs/net.eth1.lease  :  fixed-address 10.68.31.227;
/run/initramfs/net.eth1.lease  :  filename "/pxelinux.0";
/run/initramfs/net.eth1.lease  :  option subnet-mask 255.255.254.0;
/run/initramfs/net.eth1.lease  :  option dhcp-lease-time 21600;
/run/initramfs/net.eth1.lease  :  option dhcp-message-type 5;
/run/initramfs/net.eth1.lease  :  option domain-name-servers 10.68.31.135,10.68.31.136;
/run/initramfs/net.eth1.lease  :  option dhcp-server-identifier 10.68.24.48;
/run/initramfs/net.eth1.lease  :  option domain-name "tk.japannext.co.jp";
/run/initramfs/net.eth1.lease  :  renew 3 2014/01/08 05:49:59;
/run/initramfs/net.eth1.lease  :  rebind 3 2014/01/08 08:29:05;
/run/initramfs/net.eth1.lease  :  expire 3 2014/01/08 09:14:05;
/run/initramfs/net.eth1.lease  :}
/run/initramfs/net.eth1.pid    :581
/run/initramfs/net.eth1.resolv.conf    :search  tk.japannext.co.jp
/run/initramfs/net.eth1.resolv.conf    :nameserver 10.68.31.135
/run/initramfs/net.eth1.resolv.conf    :nameserver 10.68.31.136
/run/initramfs/net.ifaces      :eth1

Comment 8 Radek Vykydal 2014-02-06 15:16:36 UTC
Is there any chance you can retest with Snapshot 6? There were some changes in NetworkManager and anaconda that could fix the issue.

Comment 9 Georgi Georgiev 2014-02-07 00:42:22 UTC
(In reply to Radek Vykydal from comment #8)
> Is there any chance you can retest with Snapshot 6? There were some changes
> in NetworkManager and anaconda that could fix the issue.

I can certainly test but where do I download Snapshot 6 from? Last time I got the beta 1 from ftp://ftp.redhat.com/redhat/rhel/beta/

Comment 10 David Cantrell 2014-02-19 20:32:45 UTC
Snapshot releases are available to partner companies and companies participating in the high touch beta program.  If you are not part of this program, unfortunately you will have to wait until the final release of RHEL 7.0.  As we are unable to reproduce the issue on our end, I am marking the bug as CLOSED WORKSFORME as we are confident the issue is likely resolved in a snapshot release post beta.

Comment 11 Georgi Georgiev 2014-02-20 00:21:32 UTC
(In reply to David Cantrell from comment #10)
>  As we are unable to reproduce the issue on our end, I am marking the
> bug as CLOSED WORKSFORME as we are confident the issue is likely resolved in
> a snapshot release post beta.

Thanks. I'll confirm the fix in Beta 2 then.

Comment 12 Georgi Georgiev 2014-05-09 04:39:03 UTC
Let me reopen, as I can confirm the problem still exists in the RC. The symptoms are different this time but the root cause seems to be the same: anaconda crashes because it cannot find the @core group in any of the repositories.

Here is the same error again, which does not let me configure the extra repositories:

[anaconda root@localhost ~]# grep ERR /tmp/packaging.log 
04:21:58,516 ERR packaging: repo rhel-7-os.jnx needs an active network connection
04:21:58,523 ERR packaging: repo epel-7.jnx needs an active network connection
04:21:58,537 ERR packaging: failed to get groups for repo anaconda
04:22:11,122 ERR packaging: failed to get groups for repo anaconda

The network, however, is up:

[anaconda root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:11:07:2a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe11:72a/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3e:6c:22:96 brd ff:ff:ff:ff:ff:ff
    inet 10.68.30.30/23 brd 10.68.31.255 scope global dynamic eth1
       valid_lft 20641sec preferred_lft 20641sec
    inet6 fe80::216:3eff:fe6c:2296/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:39:7c:30 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:0d:3b:14 brd ff:ff:ff:ff:ff:ff

[anaconda root@localhost ~]# journalctl -b -x -l -a /usr/sbin/NetworkManager 
-- Logs begin at Fri 2014-05-09 04:21:13 UTC, end at Fri 2014-05-09 04:36:29 UTC. --
May 09 04:21:42 localhost NetworkManager[1201]: Internet Systems Consortium DHCP Client 4.2.5
May 09 04:21:42 localhost NetworkManager[1201]: Copyright 2004-2013 Internet Systems Consortium.
May 09 04:21:42 localhost NetworkManager[1201]: All rights reserved.
May 09 04:21:42 localhost NetworkManager[1201]: For info, please visit https://www.isc.org/software/dhcp/
May 09 04:21:42 localhost NetworkManager[1201]: Listening on LPF/eth1/00:16:3e:6c:22:96
May 09 04:21:42 localhost NetworkManager[1201]: Sending on   LPF/eth1/00:16:3e:6c:22:96
May 09 04:21:42 localhost NetworkManager[1201]: Sending on   Socket/fallback
May 09 04:21:42 localhost NetworkManager[1201]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x3c63e7d7)
May 09 04:21:42 localhost NetworkManager[1201]: DHCPACK from 10.68.30.2 (xid=0x3c63e7d7)
May 09 04:21:42 localhost NetworkManager[1201]: bound to 10.68.30.30 -- renewal in 8305 seconds.
May 09 04:21:52 localhost NetworkManager[1201]: Internet Systems Consortium DHCP Client 4.2.5
May 09 04:21:52 localhost NetworkManager[1201]: Copyright 2004-2013 Internet Systems Consortium.
May 09 04:21:52 localhost NetworkManager[1201]: All rights reserved.
May 09 04:21:52 localhost NetworkManager[1201]: For info, please visit https://www.isc.org/software/dhcp/
May 09 04:21:52 localhost NetworkManager[1201]: Listening on LPF/eth0/52:54:00:11:07:2a
May 09 04:21:52 localhost NetworkManager[1201]: Sending on   LPF/eth0/52:54:00:11:07:2a
May 09 04:21:52 localhost NetworkManager[1201]: Sending on   Socket/fallback
May 09 04:21:52 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 (xid=0x5b064bd7)
May 09 04:21:57 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 (xid=0x5b064bd7)
May 09 04:22:01 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 (xid=0x5b064bd7)
May 09 04:22:06 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 (xid=0x5b064bd7)
May 09 04:22:20 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x5b064bd7)
May 09 04:22:31 localhost NetworkManager[1201]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 (xid=0x5b064bd7)

[anaconda root@localhost ~]# cat /proc/cmdline 
method=http://10.68.31.247/cblr/ks_mirror/RHEL-7-x86_64/ ksdevice=link lang= inst.gpt ks=http://10.68.31.247/cblr/svc/op/ks/system/dcisys02 ip=eth1:dhcp text kssendmac

Comment 13 Georgi Georgiev 2014-05-12 03:56:58 UTC
This seems to only happen if trying to do the installation over "eth1". If I rearrange the interfaces on this virtual machine so that the installation is done over "eth0", everything works fine.

If installing from eth1 (in which case there is no DHCP on eth0), the installer seems to think that the system has no network connectivity, which is certainly not true. My unattended kickstart actually showed that on the screen, when I connected with VNC (obviously there is network if I can get in with VNC, right?).

Comment 14 Ludek Smid 2014-06-26 10:50:53 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Comment 15 Ludek Smid 2014-06-26 11:16:18 UTC
The comment above is incorrect. The correct version is bellow.
I'm sorry for any inconvenience.
---------------------------------------------------------------

This request was NOT resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you need
to escalate this bug.

Comment 16 Georgi Georgiev 2015-02-11 16:50:07 UTC
I was able to reproduce this issue on CentOS 7.0, and also found a workaround.

As I am using cobbler, cobbler by default generates a kickstart with multiple "network" commands - one for each interface on the system.

If I make sure that the generated kickstart only contains a single "network" command, only for the interface required for the installation, this bug is not triggered.

While this is not a solution, it is a workaround that at least makes the installation possible.

Comment 17 Radek Vykydal 2016-02-01 13:29:23 UTC
We are considering fixing the problem in rhel 7.3 release but first (as there has been many changes and networking fixes since 7.0 release) we need to check if the problem is still reproducible with RHEL 7.2. If so, please attach the log files

/tmp/anaconda.log
/tmp/syslog
/tmp/packaging.log
/tmp/ifcfg.log

Also please attach the kickstart network configuration you are using, both for working and non-working case from comment #16, if it still applies. (Ideally, we'd like to see also the installer logs for the working case from comment #16). Outputs of "ip a s" and "ip route show" for the cases might be useful too.

Thank you.

Comment 18 Georgi Georgiev 2016-02-29 23:26:43 UTC
(In reply to Radek Vykydal from comment #17)

It is still easy to reproduce. Try installing a new machine with two interfaces which are linked up, but one of which does not have any DHCP. Then change the working kickstart from

network --hostname xxxx

to

network --hostname xxx --device eth0
network --hostname xxx --device eth1

That's the only change I did and was enough to break the installation.

I have the logs, is it preferred to compress and upload them or attach them all one by one?

Comment 19 Radek Vykydal 2016-03-09 13:20:01 UTC
Please attach the logs as individual plain/text files.

Comment 20 Marek Hruscak 2016-07-27 19:45:09 UTC
May You please attach all logs and used ks.cfg? I am afraid, that without them it will be impossible to reproduce it.

In my case, anaconda is ok with eth0 without assigned address. Installation is done through eth1.

my ks.cfg have this inside:
repo --name=added_repo --baseurl=http://192.168.100.3/optional/

and kernel cmdline:
method=http://192.168.100.3/T_RHEL/ ksdevice=link lang= inst.gpt ks=http://192.168.100.3/h ip=eth1:dhcp text kssendmac net.ifnames=0 biosdevname=0 ksdevice=link

tested on KVM VM using RHEL-7.0RC

Comment 21 Georgi Georgiev 2018-03-05 23:59:34 UTC
Apologies, I have not been in a position to reproduce this in a while.

Since I don't think we have encountered this issue anymore, and it has been a few years, I think it is safe to close or reject this issue for now.

Comment 22 Jiri Konecny 2019-05-26 14:04:09 UTC
Closing this bug based on the comment 21. Thanks for your report.


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