It appears that the installer makes changes to configuration which result in network installation failing, either the loss of resolv.conf which means the hostnames of mirrors cannot be resolved or reseting the routing table, causing previously setup routes to be lost. My scenario is trying to provision virtual machines in an environment where the allocated IP addresses are also allocated specific MAC addresses. The allocated IP addresses are in a different subnet to the IP address of the host, yet ISP expects the use of the same gateway as the host. This means that you have to setup the routing table manually. So I boot the guest. At the "Welcome to FreeBSD" menu I choose shell & configure the network, also creating a resolv.conf. Everything works, I confirm I can connect to a host on the outside via TCP & ping some other hosts. Exit & choose install Configure keymap, hostname, distribution select, as I have a minimal ISO, I'm told "No installation files were found on the boot volume" and I move onto the "Network Configuration" section. Select interface say no to configuring IPv4 or IPv6 & proceed with install as normal, fetching dist files will fail. When the install has failed, exit & drop back to shell. netstart -rn will show that routing table is as you configured it but /etc/resolv.conf has been overwritten by a symlink which nolonger exists # ls -l /etc/resolv.conf lrwxr-xr-x 1 root wheel 31 Aug 12 15:45 /etc/resolv.conf -> /tmp/bsdinstall_etc/resolv.conf If you restart the install & at the "Network Configuration" section. you say yes to configuring IPV4 and no to using DHCP. You'll be presented with the details you entered manually (ip adress, mask, gw). proceeding through the install will result in again failing to fetch dist files. Dropping to the shell & running netstat you'll find that your changes to the routing table have been lost.
resetting the IP address always resets the routing table. When the IP that gives you access to the gateway goes away, the routing entries does too. Then the IP is readded, and the gateway is added. This seems to be expected behaviour, as you are asking the installer to please set my IP address and gateway to these values I entered via the dialog. So, if we fix it to not remove your resolv.conf, will that solve your problem? The installer normally assumes / and /etc are read-only, and that /etc/resolv.conf is already a symlink to /tmp/bsdinstall_etc/resolv.conf When you are manually configuring the system, are you actually removing that symlink? or writing to the /tmp destination?
(In reply to Allan Jude from comment #1) "resetting the IP address always resets the routing table." But I am not actually making any changes, just confirming the information that's read in by the installer that I'd already configured. "When the IP that gives you access to the gateway goes away, the routing entries does too. Then the IP is readded, and the gateway is added." But the installer is incapable of adding the route back in for the gateway in this scenario. As the gateway IP address is in another subnet, you first need a route to reach the gateway IP address before you are able to use that IP address as the default gateway. A better option might be to compare the information that was read in by the installer & the information confirmed by the user, if there is no difference. Don't do anything. "When you are manually configuring the system, are you actually removing that symlink? or writing to the /tmp destination?" I'm just running echo "nameserver 8.8.8.8" >> /etc/resolv.conf
(In reply to Sevan Janiyan from comment #2) "But the installer is incapable of adding the route back in for the gateway in this scenario. As the gateway IP address is in another subnet, you first need a route to reach the gateway IP address before you are able to use that IP address as the default gateway." We probably should do this, but for now, you'd just say 'no' when asked to configure the network and let it keep using your existing configuration. I would first like to focus on how/why your resolv.conf was getting clobbered. It looks like both 'auto' and 'script' entirely remove /tmp/bsdinstall_tmp when they start, and since /etc/resolv.conf is a symlink to /tmp/bsdinstall_tmp/resolv.conf on the boot media, this is where things are going wrong. I suppose it could backup resolv.conf if it exists first, then restore it.
(In reply to Allan Jude from comment #3) "I suppose it could backup resolv.conf if it exists first, then restore it." However you see fit to resolv the issue :)
For the sake of archeology, as a workaround, use an image which contains the distfiles such as disk1.iso & avoid the bootonly image.