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
What does /var/lib/tftpboot look like after the kickstart is finished? Can you share the /var/log/foreman-proxy/proxy.log?
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.
*** Bug 1379958 has been marked as a duplicate of this bug. ***
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.
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.
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.
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