Bug 206355

Summary:	Installer interferes with manual network setup, preventing netinstall from succeeding
Product:	Base System	Reporter:	Sevan Janiyan <venture37>
Component:	bin	Assignee:	freebsd-sysinstall mailing list <sysinstall>
Status:	New ---
Severity:	Affects Many People	CC:	allanjude
Priority:	---
Version:	10.2-RELEASE
Hardware:	Any
OS:	Any

Description Sevan Janiyan 2016-01-18 03:37:44 UTC

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.

Comment 1 Allan Jude freebsd_committer

2016-01-18 06:19:05 UTC

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?

Comment 2 Sevan Janiyan 2016-01-18 13:16:52 UTC

(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

Comment 3 Allan Jude freebsd_committer

2016-01-18 16:00:09 UTC

(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.

Comment 4 Sevan Janiyan 2016-01-18 18:07:48 UTC

(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 :)

Comment 5 Sevan Janiyan 2016-02-15 01:34:30 UTC

For the sake of archeology, as a workaround, use an image which contains the distfiles such as disk1.iso & avoid the bootonly image.

Comment 6 commit-hook freebsd_committer

2019-08-08 13:18:47 UTC

A commit references this bug:

Author: jbeich
Date: Thu Aug  8 13:18:38 UTC 2019
New revision: 508377
URL: https://svnweb.freebsd.org/changeset/ports/508377

Log:
  lang/crystal: unbreak runtime after r507877

  $ cat >foo.cr
  require "http/client"
  HTTP::Client.get "http://api.icndb.com/jokes/1"

  $ crystal foo.cr
  [warn] event_reinit: forked from the event_loop.
  Unhandled exception in spawn: Error reinitializing libevent (Exception)
  [warn] event_reinit: forked from the event_loop.
  Unhandled exception in spawn: Error reinitializing libevent (Exception)
  [warn] event_reinit: forked from the event_loop.
  Unhandled exception in spawn: Error reinitializing libevent (Exception)
  [warn] event_reinit: forked from the event_loop.
  [warn] event_reinit: forked from the event_loop.
  [...]

  PR:		206355
  Reported by:	Petr Fischer
  Submitted by:	Walter Schwarzenfeld
  Approved by:	Greg V (maintainer)

Changes:
  head/lang/crystal/Makefile
  head/lang/crystal/distinfo

Comment 7 Jan Beich freebsd_committer

2019-08-08 13:22:37 UTC

Sorry, comment 6 was for bug 239655. 206355 referred to attachment id.