| 2014-04-12 21:01:32 |
hexafraction |
description |
When attempting to install Ubuntu on a server with multiple network interfaces (all identical and able to boot over PXE), the installer will only attempt to use (by autoconfiguring and using to download packages) the first device, irrespective of whether that device was the one that was booted from.
Assumptions: A Ubuntu 13.04 VM on Virtualbox (bridged mode), and a target server are connected using a single ethernet crossover cable. The server in this case is based on a Super Micro X6DHE-XB motherboard, which contains a pair of Gigabit Broadcom BCM5721 adapters, both of which are enabled for booting in BIOS and as a result of jumper settings. The cable is connected to the second adapter as the motherboard (and apparently Ubuntu as well) sees it. The VM installation and server hardware are all AMD64. The installer CD is Precise Pangolin AMD64 server (though I would expect this to happen with i386, but due to limited bandwidth, did not download the i386 CD and test).
Setup process:
tftpd-hpa, and dhcp3-server are installed on the VM, and configured to listen on the VM's eth0, with a static IP of 192.168.1.4, subnet mask 255.255.255.0, and default gateway of 192.168.1.1 (this being due to applicability to another network, and not appearing to affect the boot process).
tftpd is being run with root directory /var/lib/tftpboot, in secure mode (therefore not requiring absolute paths). dhcp3-server is configured to allocate a sufficient IP range for the target server, and to pass "pxelinux.0" as the filename.
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/netboot.tar.gz (or another mirror of this file) is MD5 checked and extracted into /var/lib/tftpboot. The CD's contents are copied to Apache's default site's directory, in a subdirectory called ubuntu. In addition, the file served at http://192.168.1.4/ks.cfg reads:
install
url --url http://192.168.1.4/ubuntu/
and ks=http://192.168.0.1/ks.cfg is added to the append line of txt.cfg in ubuntu-installer/amd64/boot-screens and ubuntu-installer/i386/boot-screens
Process to replicate:
The server is booted, successfully communicates with the DHCP server over the second link, and fetches pxelinux.0 and other needed files over tftp. It displays the menu, and the user selects the "Install Ubuntu" option.
When network configuration occurs, the installer detects network hardware, waits for the link-local address, and times out trying to obtain DHCP lease information (as obviously eth0 is not connected to anything, not even a cable). Manual configuration does not help as the web-server with a copy of the CD hosted locally on the VM cannot be accessed.
Moving the cable to the the eth0's port and rebooting allows a dhcp lease to be obtained by the installer, and packages to be fetched successfully.
(the rationale being here, that in my case, and potentially others, physical placement and labeling may be misleading causing this bug).
I would expect that either the installer tries to use the second interface, or allows the user to choose between the two available. |
When attempting to install Ubuntu on a server with multiple network interfaces (all identical and able to boot over PXE), the installer will only attempt to use (by autoconfiguring and using to download packages) the first device, irrespective of whether that device was the one that was booted from.
Assumptions: A Ubuntu 13.04 VM on Virtualbox (bridged mode), and a target server are connected using a single ethernet crossover cable. The server in this case is based on a Super Micro X6DHE-XB motherboard, which contains a pair of Gigabit Broadcom BCM5721 adapters, both of which are enabled for booting in BIOS and as a result of jumper settings. The cable is connected to the second adapter as the motherboard (and apparently Ubuntu as well) sees it. The VM installation and server hardware are all AMD64. The installer CD is Precise Pangolin AMD64 server (though I would expect this to happen with i386, but due to limited bandwidth, did not download the i386 CD and test).
Setup process:
tftpd-hpa, and dhcp3-server are installed on the VM, and configured to listen on the VM's eth0, with a static IP of 192.168.1.4, subnet mask 255.255.255.0, and default gateway of 192.168.1.1 (this being due to applicability to another network, and not appearing to affect the boot process).
tftpd is being run with root directory /var/lib/tftpboot, in secure mode (therefore not requiring absolute paths). dhcp3-server is configured to allocate a sufficient IP range for the target server, and to pass "pxelinux.0" as the filename.
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/netboot.tar.gz (or another mirror of this file) is MD5 checked and extracted into /var/lib/tftpboot. The CD's contents are copied to Apache's default site's directory, in a subdirectory called ubuntu. In addition, the file served at http://192.168.1.4/ks.cfg reads:
install
url --url http://192.168.1.4/ubuntu/
and ks=http://192.168.0.1/ks.cfg is added to the append line of txt.cfg in ubuntu-installer/amd64/boot-screens and ubuntu-installer/i386/boot-screens
Process to replicate:
The server is booted, successfully communicates with the DHCP server over the second link, and fetches pxelinux.0 and other needed files over tftp. It displays the menu, and the user selects the "Install Ubuntu" option.
When network configuration occurs, the installer detects network hardware, waits for the link-local address, and times out trying to obtain DHCP lease information (as obviously eth0 is not connected to anything, not even a cable). Manual configuration does not help as the web-server with a copy of the CD hosted locally on the VM cannot be accessed.
Moving the cable to the the eth0's port and rebooting allows a dhcp lease to be obtained by the installer, and packages to be fetched successfully.
(the rationale being here, that in my case, and potentially others, physical placement and labeling may be misleading causing this bug).
I would expect that either the installer uses the boot interface (if such data is available), also tries the second interface if the first fails in any way to connect or download packages, or allows the user to choose between all interfaces that are available and up. |
|
