Bug 1406362 - tftpboot file not updated when provisioning with more than one nic
Summary: tftpboot file not updated when provisioning with more than one nic
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Networking
Version: 6.2.6
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Roman Plevka
URL:
Whiteboard:
: 1379958 (view as bug list)
Depends On:
Blocks: 1388147 1417075
TreeView+ depends on / blocked
 
Reported: 2016-12-20 11:48 UTC by Cyrus M
Modified: 2020-02-14 18:21 UTC (History)
14 users (show)

Fixed In Version: foreman-1.11.0.66-2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1417075 (view as bug list)
Environment:
Last Closed: 2017-03-06 08:36:37 UTC
Target Upstream Version:


Attachments (Terms of Use)
Full log of provisioning with multiple nics (351.54 KB, text/plain)
2016-12-20 11:48 UTC, Cyrus M
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 15238 0 Normal Closed Multiple interfaces with empty identifier are marked as invalid 2020-07-15 15:06:27 UTC
Red Hat Knowledge Base (Solution) 2835631 0 None None None 2016-12-28 01:53:44 UTC
Red Hat Product Errata RHBA-2017:0447 0 normal SHIPPED_LIVE Satellite 6.2.8 Async Bug Release 2017-03-06 13:23:41 UTC

Description Cyrus M 2016-12-20 11:48:43 UTC
Created attachment 1233798 [details]
Full log of provisioning  with multiple nics

Description of problem:
When provisioning with more than one nic, after the provisioning is complete, the host attempts to re-install when tftp boots post provision.

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


How reproducible:
Always

Steps to Reproduce:
1. Add host with 2 interfaces ( DHCP or static on interface configuration doesn't make a difference.
2. Satellite 6 is NOT the DHCP server
3. After install, the tftpboot file in /var/lib/tftpboot/pxelinux.cfg/ will not be updated for a post-provision config

Actual results:
Host attempts to rebuild ( and obviously fails )

Expected results:
tftpboot file should be updated to have the system boot from disk

Additional info:
From production.log after the system is built,
2016-12-16 13:17:18 [app] [I] Started GET "/unattended/built?token=4f2cdc7a-48cf-4d8e-a922-a466b4ab7f62" for 2606:a000:1216:803c::1f69 at 2016-12-16 13:17:18 -0500
2016-12-16 13:17:18 [app] [I] Processing by UnattendedController#built as */*
2016-12-16 13:17:18 [app] [I]   Parameters: {"token"=>"4f2cdc7a-48cf-4d8e-a922-a466b4ab7f62"}
2016-12-16 13:17:18 [app] [I] Found vmtest02.home.do-less.org
2016-12-16 13:17:18 [app] [I] unattended: vmtest02.home.do-less.org is Built!
2016-12-16 13:17:18 [app] [I] Completed 201 Created in 181ms (ActiveRecord: 67.0ms)
2016-12-16 13:17:58 [app] [I] Started GET "/unattended/provision?token=4f2cdc7a-48cf-4d8e-a922-a466b4ab7f62" for 2606:a000:1216:803c:21a:4aff:fe16:16f at 2016-12-16 13:17:58 -0500
2016-12-16 13:17:58 [app] [I] Processing by UnattendedController#host_template as */*
2016-12-16 13:17:58 [app] [I]   Parameters: {"token"=>"4f2cdc7a-48cf-4d8e-a922-a466b4ab7f62", "kind"=>"provision"}
2016-12-16 13:17:58 [app] [I] unattended: unable to find a host that matches the request from 2606:a000:1216:803c:21a:4aff:fe16:16f
2016-12-16 13:17:58 [app] [I] Filter chain halted as :get_host_details rendered or redirected
2016-12-16 13:17:58 [app] [I] Completed 404 Not Found in 8ms (ActiveRecord: 1.4ms)
2016-12-16 13:19:25 [app] [I] Started GET "/rhsm/consumers/be1f9a5c-13b0-4bcc-aa6d-fb4a37ff1b7f/compliance" for 2606:a000:1216:803c:21a:4aff:fe16:16e at 2016-12-16 13:19:25 -0500

Comment 1 Stephen Benjamin 2016-12-20 13:13:46 UTC
What does /var/lib/tftpboot look like after the kickstart is finished?

Can you share the /var/log/foreman-proxy/proxy.log?

Comment 16 Marek Hulan 2016-12-22 07:50:48 UTC
This bug was fixed in upstream, I'm linking the upstream issue. The NIC validation is not treating empty identifier correctly. While the validation method on host skips such interfaces, validation on NIC side tries to enforce uniqueness even of empty identifiers.

This causes problems during provisioning of host with multiple interfaces, preventing the TFTP change because of interface being invalid. As a simple workaround until the fix is delivered, specifying unique identifier for each interface would help, e.g. eth0 for the first, eth1 for the second.

Comment 19 Marek Hulan 2016-12-22 08:14:13 UTC
*** Bug 1379958 has been marked as a duplicate of this bug. ***

Comment 21 Roman Plevka 2017-02-20 13:29:03 UTC
Is the following step really a prerequisite for this bug? I don't see a correlation between the root cause and this step:

> 2. Satellite 6 is NOT the DHCP server

From the other comments i understand, it should be enough to create a new host with >1 NIC with no interface identifiers and wait for it to get provisioned and check whether the pxelinux.cfg file for the host is being updated to break the provisioning loop. Is this verification procedure correct?

thanks.

Comment 22 Marek Hulan 2017-03-01 07:10:47 UTC
No it's not required. The problem was for any host with more than one NIC. The easiest way to reproduce is to create a host with two interfaces with empty identifiers. Then try editing the host, e.g. changing the comment attribute. It fails on interface identifier being already taken. The same failure prevents host saving during provisioning hence tftp is not changed. See comment 16 for more details.

Comment 23 Roman Plevka 2017-03-02 10:02:23 UTC
VERIFIED
on sat6.2.8-4

- provisioned a host via libvirt that had 2 interfaces defined without any if id.
- the orchestration worked smoothly and foreman updated the pxelinux.cfg file as expected.

Comment 25 errata-xmlrpc 2017-03-06 08:36:37 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-2017:0447


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