Created attachment 496925 [details] Diff of i386 and x86_64 initrd.img contents Description of problem: Attempting an NFS install seems to fail on x86_64. A cursory inspection seems to indicate that DNS didn't get setup properly. If I <ctrl>Z to a shell, run `dhclient -v <device>` ... and re-attempt to install using NFS ... it works fine. Using teh same procedure, installing F-15-TC1-i386 on the same systems does works fine and does *not* show this problem. However, I've managed to encounter this problem on multiple bare metal systems. Version-Release number of selected component (if applicable): * anaconda-15.30-1 How reproducible: * Reproducible on 2 of 2 bare metal tests, but not reproducible on virt (perhaps just how virt-install differs) Steps to Reproduce: 1. Boot the installer (PXE) with "askmethod" 2. Select language and keymap 3. Select NFS 4. Enter a valid server and path 5. Select a network device (only if multiple NICs are on system) Actual results: The URL provided does not contain installation media Expected results: Loader transitions to anaconda without error Additional info: * Entirely possible it's something I'm doing wrong here. I've reproduced the problem on bare metal, granted using the same NFS server. * Attaching a diff of the i386 and x86_64 initrd contents ... * Attaching anaconda log files from the x86_64 failure case ... * If this bug holds, it qualifies as a Final release blocker due to the Beta criteria [1] - "The installer must be able to use the HTTP, FTP and NFS remote package source options " [1] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
Created attachment 496927 [details] logs from x86_64 NFS failure (tgz) # tar -ztvf anaconda-logs-x86_64.tgz -rw-r--r-- root/root 228 2011-05-04 16:23 etc/resolv.conf -rw-r--r-- root/root 56 2011-05-04 16:23 etc/sysconfig/network -rw-r--r-- root/root 125 2011-05-04 16:23 etc/sysconfig/network-scripts/ifcfg-eth0 -rw-r--r-- root/root 3461 2011-05-04 16:23 tmp/anaconda.log -rw-r--r-- root/root 541 2011-05-04 16:23 tmp/program.log -rw-r--r-- root/root 81569 2011-05-04 16:36 tmp/syslog
I see this in syslog: 20:22:31,0 NOTICE NetworkManager: ifcfg-rh: Ignoring connection 'System eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN Later on it says it brought up eth0, I assume that was when you ran dhclient. Can you try again and grab /etc/sysconfig/network-scripts/ifcfg-eth0 without doing anything on the command line. also, please attach log files as individual files, it makes it easier to read.
(In reply to comment #2) > I see this in syslog: > > 20:22:31,0 NOTICE NetworkManager: ifcfg-rh: Ignoring connection 'System > eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN This is when ifcfg file is first written by anaconda. > > Later on it says it brought up eth0, I assume that was when you ran dhclient. > This is when network is activated after selecting nfs method. James, you just don't seem to specify dns server for static (therefore dhclient is not run) configuration: 20:22:27,637 INFO loader: kernel command line: 20:22:27,637 INFO loader: initrd=/images/F-15-Final-x86_64/initrd.img 20:22:27,637 INFO loader: askmethod 20:22:27,637 INFO loader: BOOT_IMAGE=/images/F-15-Final-x86_64/vmlinuz 20:22:27,637 INFO loader: ip=10.10.9.1:10.10.9.125:10.10.11.254:255.255.252.0 20:22:27,637 INFO loader: BOOTIF=01-00-17-08-2a-72-3d /* parse anaconda or pxelinux-style ip= arguments * pxelinux format: ip=<client-ip>:<boot-server-ip>:<gw-ip>:<netmask> * anaconda format: ip=<client-ip> netmask=<netmask> gateway=<gw-ip> */ so nfs server resolution fails. I suppose this should fail in the same way on i386. Perhaps the ip= argument preventing default dhcp configuration got there by accident from pxe in this case?
(In reply to comment #3) > 20:22:27,637 INFO loader: kernel command line: > 20:22:27,637 INFO loader: initrd=/images/F-15-Final-x86_64/initrd.img > 20:22:27,637 INFO loader: askmethod > 20:22:27,637 INFO loader: BOOT_IMAGE=/images/F-15-Final-x86_64/vmlinuz > 20:22:27,637 INFO loader: > ip=10.10.9.1:10.10.9.125:10.10.11.254:255.255.252.0 > 20:22:27,637 INFO loader: BOOTIF=01-00-17-08-2a-72-3d > > /* parse anaconda or pxelinux-style ip= arguments > * pxelinux format: ip=<client-ip>:<boot-server-ip>:<gw-ip>:<netmask> > * anaconda format: ip=<client-ip> netmask=<netmask> gateway=<gw-ip> > */ > > so nfs server resolution fails. I suppose this should fail in the same way on > i386. Perhaps the ip= argument preventing default dhcp configuration got there > by accident from pxe in this case? Very ODD indeed! I didn't realize that PXE args were being passed in my case for this system. I'm thankful you spotted that. Somehow that ip= value is being supplied by PXE ... I don't see it on the PXE command-line when booting. Clearly this is a misconfiguration more than anything else, but I'm perplexed as to where those options are coming from.
(In reply to comment #4) > Clearly this is a misconfiguration more than anything else, but I'm perplexed > as to where those options are coming from. My pxelinux.cfg/default for the F-15-Final-TC1-x86_64 boot target contains ... LABEL F-15-Final-x86_64 kernel /images/F-15-Final-x86_64/vmlinuz MENU LABEL F-15-Final-x86_64 append initrd=/images/F-15-Final-x86_64/initrd.img ipappend 2 ^^^^^^ This is what is adding the ip= value and causing the problems I'm seeing in this report. http://syslinux.zytor.com/wiki/index.php/SYSLINUX#IPAPPEND_flag_val_.5BPXELINUX_only.5D I'm going to retest without that option and make sure all is right ...
I tested F-15-final-tc1 x86_64 nfs install on bare metal(Hardware raid), but didn't reproduce this issue. My steps were very similar: 1. Boot the installer (PXE) with "askmethod" 2. Select language and keymap 3. Select NFS 4. Enter a valid server and path 5. Select a network device (multiple NICs are on system) The nfs repo could be retrieved and installed successfully.
(In reply to comment #6) > The nfs repo could be retrieved and installed successfully. So it seems the problem I was seeing is caused by a pxelinux.cfg/default configuration issue. My configuration is using "ipappend 2", this causes pxelinux to pass the ip=...:...: values to the kernel, which end up not supplying all the required information for proper networking (dns), and cause this issue. I'm going to close this as NOTABUG for now, since this is introduced by user-configuration. I'm just surprised I haven't hit this before.