RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1293051 - inst.dhcpclass is not passed up the stack
Summary: inst.dhcpclass is not passed up the stack
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Chris Lumens
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-19 17:26 UTC by Ashley Penney
Modified: 2016-11-03 23:21 UTC (History)
4 users (show)

Fixed In Version: anaconda-21.48.22.80-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 23:21:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2158 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2016-11-03 13:13:55 UTC

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
Note You need to log in before you can comment on or make changes to this bug.