Bug 1575026
| Summary: | Can't PXE/iPXE boot with dnsmasq and DHCPv6 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Derek Higgins <derekh> | ||||||||||
| Component: | dnsmasq | Assignee: | Petr Menšík <pemensik> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 7.5 | CC: | bfournie, dsinglet, hjensas, lzap, marjones, mhulan, thozza | ||||||||||
| Target Milestone: | rc | Keywords: | FutureFeature, Patch, Reopened | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | |||||||||||||
| : | 1779187 1804382 1810172 (view as bug list) | Environment: | |||||||||||
| Last Closed: | 2020-04-21 12:51:07 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: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1459187, 1779187, 1780662, 1782947, 1804382, 1810172 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Derek Higgins
2018-05-04 14:56:07 UTC
Note I've also seen this issue just with PXE. The flow is like this: UEFI PXE client sends a Solicit with DNS option request Dnsmasq responds with IPv6 address and DNS option response UEFI PXE client sends a 2nd solicit with BootUrl and BootFileParamaters option requests and a different IAID Dnsmasq responds with "no addresses available" Tomas - unfortunately the fact that the patch is upstream doesn't mean it will get approved and merged. That patch just hit its 1 year anniversary and the submitter again requested inclusion (see [1]), but the upstream maintainer does not seem to be inclined to include it. Is there any possibility of including this patch just downstream? Do we have any precedence for this in dnsmasq? Thanks. [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013623.html (In reply to Bob Fournier from comment #10) > Tomas - unfortunately the fact that the patch is upstream doesn't mean it > will get approved and merged. That patch just hit its 1 year anniversary > and the submitter again requested inclusion (see [1]), but the upstream > maintainer does not seem to be inclined to include it. > > Is there any possibility of including this patch just downstream? Do we > have any precedence for this in dnsmasq? Thanks. > > > [1] > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013623.html We recently included one critical fix as a downstream patch, but it is definitely not something that we want to continue doing. dnsmasq's code is hard to maintain and any downstream change makes it even harder to maintain and to keep the functionality in new upstream version. Working with upstream to include a different version of the fix or possibly changing dnsmasq for something different is a preferred way to go. My understanding is that Open Stack runs not only on RHEL, how are other distributions solving this issue? Created attachment 1664048 [details]
RPM SPEC file with the 3 patches attached to this bug.
Created attachment 1664049 [details]
Patch30
Created attachment 1664050 [details]
Patch31
Created attachment 1664051 [details]
Patch32
Ack to LZaps comment 24. Not needed for RHEL7 but instead for RHEL8. NeedInfo flag reset. |