resolv.conf symlink is broken after clean debootstrap

Status changed to 'Confirmed' because the bug affects multiple users.

Bug introduced with this commit.

https://git.launchpad.net/~usd-import-team/ubuntu/+source/systemd/commit/?id=76e5adfa6d1fb60e9622ca4b0d03a5b4f130885a

This may have been fixed just now by demoting resolvconf from important to extra. If the next image build is still broken after this change, please shout.

Ideally the debootstrap would have worked at all points without archive override changes, but having missed that, we should just get resolvconf out of the way.

Correct that there is a bug with debootstrap above, if both this new systemd & resolvconf are being bootstrapped together. (as both src:systemd and src:resolvconf try to setup /etc/resolv.conf symlink)

Dropping resolvconf from important should resolve this.

The ExecStartPre change should then be dropped.

Adding resolvconf task as well, since now:
$ sudo debootstrap --include=resolvconf artful artful

is broken.

This bug was fixed in the package resolvconf - 1.79ubuntu8

---------------
resolvconf (1.79ubuntu8) artful; urgency=medium

  * Dereference /etc/resolf.conf when creating runtime configuration when
    migrating to resolvconf managed /etc/resolv.conf. The contents of
    /etc/resolv.conf (rather than the symlink target information) is
    needed in /run/resolvconf/resolv.conf and
    /run/resolvconf/interface/original.resolvconf during migration until
    resolvconf updates the config next. LP: #1713149

 -- Dimitri John Ledkov <email address hidden> Tue, 29 Aug 2017 14:04:33 +0100

artful preseed installs are still failing for me because of hostname resolutions during in-target.

After base-installer completes, the in-target installation fails to resolve the artful repositories. The target has /etc/resolv.conf but /etc/resolv.conf is not working or available through in-target. in-target is missing the entire /run/systemd directory.

# chroot /target ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Aug 29 22:32 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

# chroot /target ls -l /run/systemd/resolve/
total 4
-rw-r--r-- 1 root root 89 Aug 29 22:32 stub-resolv.conf

# chroot /target cat /etc/resolv.conf
search <redacted>
nameserver <redacted>

# chroot /target ls -l /run
total 12
drwxrwxrwt 2 root root 4096 Aug 29 22:30 lock
drwxr-xr-x 2 root root 4096 Aug 29 22:30 mount
drwxr-xr-x 3 root root 4096 Aug 29 22:32 systemd
-rw-rw-r-- 1 root utmp 0 Aug 29 22:30 utmp

# in-target ls -l /etc/resolv.conf
Aug 29 22:37:04 in-target: lrwxrwxrwx 1 root root 39 Aug 29 22:32 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

# in-target ls -l /run/systemd/resolve/
Aug 29 22:40:27 in-target: ls: cannot access '/run/systemd/resolve/'
Aug 29 22:40:27 in-target: : No such file or directory

# in-target cat /etc/resolv.conf
Aug 29 22:41:48 in-target: cat: /etc/resolv.conf
Aug 29 22:41:48 in-target: : No such file or directory

# in-target ls -l /run/
Aug 29 22:44:32 in-target: total 0
Aug 29 22:44:32 in-target: drwxr-xr-x 2 root root 40 Aug 29 22:26 lock
Aug 29 22:44:32 in-target: drwxr-xr-x 2 root root 60 Aug 29 22:26 mount
Aug 29 22:44:32 in-target: drwxr-xr-x 4 root root 100 Aug 29 22:30 udev

@vlee please open a new bug report, and please extract and attach debian-installer logs, e.g. /var/log/syslog from the d-i environment.

Hi,

(installing Bionic here)

a possible solution is to make sure, /target/run is already mounted (bind-mount to /run) when debootstrap is running which will make systemd create its resolv.conf copy in the correct /run-filesystem. Otherwise, it would write to the /target-partition and in-target would hide the stuff in there when doint its bind-mounts.

For now I create (and make executable) the script /usr/lib/base-installer.d/41init-run via early_command:

#!/bin/sh
mkdir -p /target/run
mount --bind /run /target/run

IMHO this should be done by the base-installer.