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 1177984 - Anaconda does not use IPv6 gateway from kernel boot line during PXE
Summary: Anaconda does not use IPv6 gateway from kernel boot line during PXE
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
Clayton Spicer
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1361708
TreeView+ depends on / blocked
 
Reported: 2015-01-01 01:05 UTC by Paul Wayper
Modified: 2019-02-15 13:58 UTC (History)
7 users (show)

Fixed In Version: anaconda-13.21.255-1
Doc Type: Bug Fix
Doc Text:
The "gateway" installation boot option now handles *IPv6* addresses Previously, the "gateway" boot option in the installation system supported only *IPv4* addresses. With this update, it is possible to configure an *IPv6* gateway, using the "gateway" boot option, during installation.
Clone Of:
: 1285857 (view as bug list)
Environment:
Last Closed: 2017-03-21 11:08:44 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
anaconda.log (2.76 KB, text/plain)
2016-03-14 17:55 UTC, Jan Stodola 		no flags Details
syslog (57.62 KB, text/plain)
2016-03-14 17:56 UTC, Jan Stodola 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0720 0 normal SHIPPED_LIVE anaconda bug fix update 2017-03-21 12:41:58 UTC

Description Paul Wayper 2015-01-01 01:05:50 UTC 
Description of problem:

Customer is using an IPv6 only network with a Satellite server on a central network.  Virtual machines are booted on a remote network (again IPv6 only) using PXE.  The kernel boot parameters (amended to use documentation range) are:

initrd=/images/ks-rhel-x86_64-server-6-66/initrd.img ks=http://satellite.example.com/pub/test.ks ksdevice=bootif lang= ipv6=2001:db8:2764:d02a::2/64 ipv6gateway=2001:db8:2764:d02a::1 nameserver=2001:db8:2764:e064::253:10 noipv4

When the virtual machine boots, it does not configure its IPv6 address and gateway correctly.  Network traffic from the virtual machine never pings the gateway, and the machine remains unpingable on the 2001:db8:2764:d02a::/64 network.  Instead, the new machine sends out IPv6 router solicitation requests, which seems to indicate that the gateway and IPv6 address have not been set on the interface.

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

anaconda 13.21.229

How reproducible:

Every time.

Steps to Reproduce:
1. Set up IPv6 only network:
1a. Satellite server on network A
1b. DNS server on network A
1c. Gateway router between network A and network B
1c. BootP/TFTP server on network B
1d. Virtual machine on network B using static IPv6 address
1f. No machines to use IPv4 addresses.
1g. No DHCP or DHCPv6 servers and no IPv6 router advertisement.

2. Set up BootP/TFTP server with kickstart to download files and connect to Satellite server on remote network A

3. Boot virtual machine with PXE.

Expected results:

A. Virtual machine sets up gateway and IPv6 addresses.
B. Virtual machine gets AAAA record of satellite server from DNS server.
C. Virtual machine fetches kickstart file from remote satellite server.

Actual results:

A. Virtual machine does not set up IPv6 address and cannot be pinged from network B.
B. Virtual machine does not set up gateway and instead tries DHCPv6 and router solicitation.

Additional info:

Masahiro Matsuya has produced an initrd file that fixed this issue.  I'm cc'ing him on this bug so he can add his notes on what he fixed.
Comment 2 Samantha N. Bueno 2015-07-17 19:14:44 UTC 
(In reply to Paul Wayper from comment #0)
> 
> Additional info:
> 
> Masahiro Matsuya has produced an initrd file that fixed this issue.  I'm
> cc'ing him on this bug so he can add his notes on what he fixed.

Hi Masahiro, any chance you can provide the details Paul mentioned to help us debug this?
Comment 3 Masahiro Matsuya 2015-07-21 05:30:53 UTC 
Hello Samantha,

Unfortunately, I lost the exact patch used to create the test initrd.img. I backported from https://git.fedorahosted.org/cgit/anaconda.git/commit/?h=f15-branch&id=659e027775ef81b5656e987ec648cf2b5454c688.

This patch enables gateway= boot parameter to be used with IPv6 gateway IP address. This is one of the related patches for bz#677609 in https://git.fedorahosted.org/cgit/anaconda.git/log/?h=f15-branch&qt=grep&q=677609. But, 52cd3fc045429f5f271fb8b6970457b7dea4aef8 has already been included in RHEL6, and 528046666bfb6e4e0ba7f88044736a8bbcf1c897 is not must.

But, with initrd.img with the above patch, it failed to download a kickstart file. But, it could proceed the installation with selecting 'OK' button to retry downloading it. So, they still have some timing issue.

I wanted to check the network configuration with another initrd.img with a *debug* code to retry downloading kickstart 10 times automatically and to output the network status on the failure. If I remember correctly, I added the change into urlinstTransfer() of urls.c. It's not to confirm the fix with it, but it's to collect the debug information. But, the problem didn't happen with it and the requested data was not provided unfortunately. Basically, I don't think it's good idea to add the retry code for it. It's better to investigate how the first download of kickstart failed and make a patch for it, but the case was closed already and we don't have reproducer.

At least, 659e027775ef81b5656e987ec648cf2b5454c688 should be fixed on this bugzilla. But, I don't think we should add the retry code, though it's just my opinion.

Thanks,
Masahiro
Comment 4 Radek Vykydal 2015-10-22 11:58:32 UTC 
So from Masahiro's analysis it seems the issue is caused by not setting the ipv6 gateway via boot options. We should either port the patch, or maybe rather add dedicated ipv6gateway boot option (as used in the descritption).
Comment 5 Radek Vykydal 2016-01-05 15:37:05 UTC 
(In reply to Masahiro Matsuya from comment #3)
> At least, 659e027775ef81b5656e987ec648cf2b5454c688 should be fixed on this
> bugzilla. But, I don't think we should add the retry code, though it's just
> my opinion.

Agreed, sent port of the patch from f15-branch for review.
Comment 7 Jan Stodola 2016-03-14 17:55:04 UTC 
Radek,
I have a problem downloading install.img when using IPv6. Anaconda says it couldn't download it, but when I retry it, the file is downloaded successfully and the installation continues. Network settings look OK to me when this happens:

# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fd00:dead:beef:56::20/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe60:e1b0/64 scope link 
       valid_lft forever preferred_lft forever

# ip -6 r
fd00:dead:beef:56::/64 dev eth0  proto kernel  metric 256  mtu 1500
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500
default via fd00:dead:beef:56::10 dev eth0  proto static  metric 1  mtu 1500

The kernel cmdline options: repo=http://[fd00:dead:beef:55::20]/68 ipv6=fd00:dead:beef:56::20/64 gateway=fd00:dead:beef:56::10

Tested with anaconda-13.21.247-1.el6. Logs will be attached, moving to ASSIGNED.
Comment 8 Jan Stodola 2016-03-14 17:55:42 UTC 
Created attachment 1136237 [details]
anaconda.log
Comment 9 Jan Stodola 2016-03-14 17:56:04 UTC 
Created attachment 1136238 [details]
syslog
Comment 11 Samantha N. Bueno 2016-03-31 21:18:27 UTC 
Dropped from the errata due to FailedQA status. We're out of time for 6.8 and this is a non-blocking issue. We'll re-visit this for 6.9, so I'll set the flags for that release.
Comment 13 Radek Vykydal 2016-10-13 12:49:56 UTC 
According to comment #7, the patch/fix that was intended to be included in 6.8 really resolves what was originally aimed to be fixed in scope of this bug (comment #3): fixing the support of ipv6 for gateway installer boot option. I will investigate the further issue - install.img being downloaded only after retry in UI. I was able to reproduce it locally.
Comment 14 Radek Vykydal 2016-10-13 15:29:10 UTC 
(In reply to Radek Vykydal from comment #13)

> ... I will investigate the further issue - install.img being downloaded
> only after retry in UI. I was able to reproduce it locally.

Adding NM debug logging reveals that we are missing /bin/ping6 in installer image:

14:47:02,619 INFO NetworkManager: <debug> [1476370022.619350] [nm-system.c:317] sync_addresses(): (eth1): adding address '2001:cafe:cafe:8::4/0'
14:47:03,620 INFO NetworkManager: <debug> [1476370023.620009] [nm-device.c:3859] spawn_ping(): (eth1): running '/bin/ping6 -I eth1 -c 1 -w 3 2001:cafe:cafe:8::3'
14:47:03,623 WARNING NetworkManager: <warn> could not spawn /bin/ping6: Failed to execute child process "/bin/ping6" (No such file or directory)

which is causing the first http request failing to reach the the server:

15:42:56.958091 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
15:42:57.768124 IP6 :: > ff02::1:fff3:dc4e: ICMP6, neighbor solicitation, who has fe80::5054:ff:fef3:dc4e, length 24
15:42:58.926068 IP6 fe80::5054:ff:fef3:dc4e > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
15:42:59.225184 IP6 :: > ff02::1:ff00:4: ICMP6, neighbor solicitation, who has 2001:cafe:cafe:8::4, length 24
15:42:59.935118 IP6 fe80::5054:ff:fef3:dc4e > ff02::1:ff00:3: ICMP6, neighbor solicitation, who has 2001:cafe:cafe:8::3, length 32
15:42:59.935179 IP6 2001:cafe:cafe:8::3 > fe80::5054:ff:fef3:dc4e: ICMP6, neighbor advertisement, tgt is 2001:cafe:cafe:8::3, length 32
15:42:59.936117 IP6 fe80::5054:ff:fef3:dc4e.52188 > 2001:cafe:cafe:7::1.http: Flags [S], seq 2736847660, win 14400, options [mss 1440,sackOK,TS val 4294685315 ecr 0,nop,wscale 7], length 0
15:42:59.936193 IP6 fe80::5054:ff:fea9:b08f > fe80::5054:ff:fef3:dc4e: ICMP6, destination unreachable, beyond scope 2001:cafe:cafe:7::1, source address fe80::5054:ff:fef3:dc4e, length 88
15:42:59.940079 IP6 fe80::5054:ff:fef3:dc4e.52189 > 2001:cafe:cafe:7::1.http: Flags [S], seq 450115356, win 14400, options [mss 1440,sackOK,TS val 4294685321 ecr 0,nop,wscale 7], length 0
15:42:59.940113 IP6 fe80::5054:ff:fea9:b08f > fe80::5054:ff:fef3:dc4e: ICMP6, destination unreachable, beyond scope 2001:cafe:cafe:7::1, source address fe80::5054:ff:fef3:dc4e, length 88
15:42:59.946094 IP6 fe80::5054:ff:fef3:dc4e.52190 > 2001:cafe:cafe:7::1.http: Flags [S], seq 1979673574, win 14400, options [mss 1440,sackOK,TS val 4294685327 ecr 0,nop,wscale 7], length 0
15:42:59.946109 IP6 fe80::5054:ff:fea9:b08f > fe80::5054:ff:fef3:dc4e: ICMP6, destination unreachable, beyond scope 2001:cafe:cafe:7::1, source address fe80::5054:ff:fef3:dc4e, length 88
15:43:04.948467 IP6 fe80::5054:ff:fea9:b08f > fe80::5054:ff:fef3:dc4e: ICMP6, neighbor solicitation, who has fe80::5054:ff:fef3:dc4e, length 32
15:43:04.949056 IP6 fe80::5054:ff:fef3:dc4e > fe80::5054:ff:fea9:b08f: ICMP6, neighbor advertisement, tgt is fe80::5054:ff:fef3:dc4e, length 24
15:43:08.293169 IP6 fe80::5054:ff:fef3:dc4e > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
15:43:09.948069 IP6 fe80::5054:ff:fef3:dc4e > fe80::5054:ff:fea9:b08f: ICMP6, neighbor solicitation, who has fe80::5054:ff:fea9:b08f, length 32
15:43:09.948108 IP6 fe80::5054:ff:fea9:b08f > fe80::5054:ff:fef3:dc4e: ICMP6, neighbor advertisement, tgt is fe80::5054:ff:fea9:b08f, length 24
Comment 15 Radek Vykydal 2016-10-14 08:52:39 UTC 
https://github.com/rhinstaller/anaconda/pull/827
Comment 16 Radek Vykydal 2016-10-17 08:22:23 UTC 
Summary:
- support for ipv6 in gateway boot option has been added already in 6.8
- http request fail (dropping to loader tui) should be fixed in the next build of 6.9 (anaconda-13.21.255-1)
Comment 20 Radek Vykydal 2017-01-04 11:38:01 UTC 
Looks okay to me.
Comment 22 errata-xmlrpc 2017-03-21 11:08:44 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/RHBA-2017-0720.html
Note You need to log in before you can comment on or make changes to this bug.