Bug 1293051

Summary: inst.dhcpclass is not passed up the stack
Product: Red Hat Enterprise Linux 7 Reporter: Ashley Penney <apenney>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: james-p, jstodola, mkovarik, rvykydal
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-21.48.22.80-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 23:21:08 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:

Description Ashley Penney 2015-12-19 17:26:20 UTC
Description of problem:

I wish to install RHEL, via kickstart, using DHCP.  To do this in my environment I need a custom dhcp vendor identifier.  There are options, "dhcpclass", to do this but it doesn't reach the highest level of anaconda properly.

Process from my perspective:

Server starts.
PXEClient DHCPs a public ip in a build range by matching on vendor identifier.

It uses the configuration file:

```
DEFAULT linux

LABEL linux
    KERNEL boot/Fedora-23-x86_64-vmlinuz
        APPEND initrd=boot/Fedora-23-x86_64-initrd.img ks=http://build00.internal.ntoggle.com:80/unattended/provision ks.device=bootif network ks.sendmac inst.dhcpclass=foreman
        IPAPPEND 2
```

This then starts (dracut?).
Dracut does a DHCP request with the foreman dhcpclass correctly, and gets the same lease.

At this point the automated install is started and we proceed until we reach:

network --onboot=no --bootproto dhcp --hostname node00.internal.ntoggle.com --device=fc:aa:14:ae:f8:d2 --dhcpclass=foreman

This then initiates another DHCP request with -no vendor identifier- as verified with Wireshark.  It gets DHCPNAKed and fails to install at this point.
 
From the DHCPd perspective:

DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease
DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease
DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPREQUEST for 66.150.120.242 from fc:aa:14:ae:f8:d2 via enp2s0f0: lease 66.150.120.242 unavailable.
DHCPNAK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0

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

I have tested this against RHEL7.2 and Fedora 23.

How reproducible:

Well, every time? :)

Steps to Reproduce:
1. Set inst.dhcpclass=something in a pxeboot
2. Set --dhcpclass=something in a kickstart
3. Watch it fail to make it to dhcpd.

Actual results:

A failed lease attempt.

Expected results:

The lease is picked back up.

Additional info:

Comment 2 James Pearson 2016-07-08 16:11:22 UTC
I've been banging my head against this problem for the last couple of days - until I found this BZ ...

For what it's worth, I've managed to work round the problem by using an Anaconda updates image containing just the file /etc/dhcp/dhclient.conf - which contains the line:

 send vendor-class-identifier "myclass";

Comment 4 Michal Kovarik 2016-09-06 09:48:58 UTC
Verified on RHEL-7.3-20160901.1 with anaconda-21.48.22.86-1. dhcpclass from kernel cmdline is used in installer.

Comment 6 errata-xmlrpc 2016-11-03 23:21:08 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://rhn.redhat.com/errata/RHEA-2016-2158.html