Hijack on ubuntu breaks DNS making `brl fetch` appear to fail

[nikvdp]

bedrock-linux-0.7.6-x86_64.sh --hijack on a fresh Ubuntu 18.04 (bionic) install breaks DNS causing brl fetch to fail.

Steps to reproduce:

• Install Ubuntu 18.04
• Bedrock hijack:

  wget https://github.com/bedrocklinux/bedrocklinux-userland/releases/download/0.7.6/bedrock-linux-0.7.6-x86_64.sh
  chmod +x bedrock-linux-0.7.6-x86_64.sh
  sudo ./bedrock-linux-0.7.6-x86_64.sh  --hijack

• Reboot.
• brl fetch fails with confusing error message until you realize DNS is non-functional

  sudo brl fetch arch
  [ 1/15 (  6%)}] Determining name
  * Using arch
  [ 2/15 ( 13%)}] Determining CPU architecture
  * Using x86_64
  [ 3/15 ( 20%)}] Determining release
  * Using rolling
  [ 4/15 ( 26%)}] Determining mirror
  * Checking bedrock.conf [brl-fetch-mirror] items
  [\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\] 100%
  ERROR: Unable to automatically find a valid mirror.  Manually specify mirror with `--mirror`.
  ERROR: Unexpected error occurred. 

• Manually populating /etc/resolv.conf works around the issue:

  echo "nameserver 1.1.1.1"  | sudo tee /etc/resolv.conf 

  ubuntu-bionic:~$ sudo brl fetch arch
  [ 1/15 (  6%)}] Determining name
  * Using arch
  [ 2/15 ( 13%)}] Determining CPU architecture
  * Using x86_64
  [ 3/15 ( 20%)}] Determining release
  * Using rolling
  [ 4/15 ( 26%)}] Determining mirror
  * Checking bedrock.conf [brl-fetch-mirror] items
  [\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\] 100%
  * Fast filtering 154 to top 10
  [\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\] 100%
  * Finding fastest mirror from 1
  [\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\] 100%
  * Using https://mirror.osbeck.com/archlinux/
  [ 5/15 ( 33%)}] Making bootstrap directory structure
  [ 6/15 ( 40%)}] Downloading bootstrap software
  Looking for file matching: ^archlinux-bootstrap-[^-]*-x86_64[.]tar[.]gz$
  at: https://mirror.osbeck.com/archlinux//iso/latest/
  found: archlinux-bootstrap-2019.07.01-x86_64.tar.gz
  Connecting to mirror.osbeck.com (104.25.194.31:443)
  bootstrap.tar.gz      14% |******                                          | 21.0M  0:01:05 ETA
  ...
  

[nift4]

@nikvdp What is your bedrock.conf?

[paradigm]

I can reproduce the issue. As a temporary work around, as root, edit /bedrock/share/resolvconf/00bedrock. It should initially look like

#!/bin/sh
#
# resolvconf requires /etc/resolv.conf to be a symlink to
# /etc/resolvconf/run/resolv.conf, but it does not create this symlink itself.
# Provided /etc/resolv.conf does not exist - no other subsystem is controlling
# the file - create it to fullfill resolvconf's requirements.
#
if ! [ -e /etc/resolv.conf ] &&
    ! [ -h /etc/resolv.conf ]; then
    ln -s /etc/resolvconf/run/resolv.conf /etc/resolv.conf
fi

Clear out everything but the top line so it looks like:

#!/bin/sh

then save the file and reboot, after which DNS should work as expected.

I plan to push a proper fix with the next Bedrock update which should overwrite the work around such that you do not need to remember to revert it later, just brl update.

---

Different distros/inits/networking stacks/etc handle /etc/resolv.conf differently. Many become upset if they see a resolv.conf file from another system, such as if you reboot between different init systems via Bedrock. Bedrock's strategy to avoid conflicts here is to just delete /etc/resolv.conf with the expectation that the desired init re-creates it.

resolvconf (no .) is a /etc/resolv.conf management system which creates a resolv.conf file in a location other than /etc/resolv.conf and which assumes /etc/resolv.conf is a symlink to this location. It does not create this symlink on its own, which means when Bedrock removes /etc/resolv.conf nothing recreates or redirects it and DNS fails to work.

To make Bedrock work with resolvconf systems, I wrote a resolvconf hook to create the symlink if it is missing. With Ubuntu 18.04 (and derivative distros such as Pop!_OS), Ubuntu keeps resolvconf around but uses another system (I think systemd) to manage resolv.conf. The Bedrock resolvconf hook creates a symlink that conflicts with this other system. This is what you've run into, and why clearing out the hook is an adequate work around.

This hook is needed for some systems, and so that work-around is not a viable general long term solution. My plan here is to make the corresponding hook smarter about when it creates the symlink and where the symlink points. I expect to have a fix out with the next Bedrock update, but it may be a couple weeks or so before I can get the update out as I have a very large back log of things that need to make it into the update and it's taking me time to work through them.