Default /etc/resolv.conf mount incompatible with systemd

[micchickenburger]

Related to #22, when using a systemd-based image like Ubuntu 18.04.4 LTS, the default mount of /etc/resolv.conf fails:

==> arm-image: Retrieving Image
==> arm-image: Trying http://cdimage.ubuntu.com/releases/18.04.4/release/ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz
==> arm-image: Trying http://cdimage.ubuntu.com/releases/18.04.4/release/ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz?checksum=sha256%3Af270d4a11fcef7f85ea77bc0642d1c6db2666ae734e9dcc4cb875a31c9f0dc57
==> arm-image: http://cdimage.ubuntu.com/releases/18.04.4/release/ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz?checksum=sha256%3Af270d4a11fcef7f85ea77bc0642d1c6db2666ae734e9dcc4cb875a31c9f0dc57 => /vagrant/packer_cache/4cc54ff9b15315c3bf2ae2264e8b6d072d8b8e5b.iso
==> arm-image: Copying source image.
==> arm-image: Image is a xz file.
    arm-image: Speed:   57.65 MB/s
    arm-image: Speed:   48.52 MB/s
    arm-image: mapping output-arm-image/image
==> arm-image: kpartx -s -a -v output-arm-image/image
==> arm-image: partitions: [/dev/mapper/loop0p1 /dev/mapper/loop0p2]
    arm-image: Mounting: /dev/mapper/loop0p2
    arm-image: Mounting: /dev/mapper/loop0p1
==> arm-image: Mounting additional paths within the chroot...
    arm-image: Mounting: /proc
    arm-image: Mounting: /sys
    arm-image: Mounting: /dev
    arm-image: Mounting: /dev/pts
    arm-image: Mounting: /proc/sys/fs/binfmt_misc
==> arm-image: Error creating mount directory: mkdir /tmp/517734997/etc/resolv.conf: file exists
==> arm-image: fuser -k /tmp/517734997
Build 'arm-image' errored: Error creating mount directory: mkdir /tmp/517734997/etc/resolv.conf: file exists

==> Some builds didn't complete successfully and had errors:
--> arm-image: Error creating mount directory: mkdir /tmp/517734997/etc/resolv.conf: file exists

==> Builds finished but no artifacts were created.

/etc does exist and so does /etc/resolv.conf; however it's a symbolic link to ../run/systemd/resolve/stub-resolv.conf which does not exist without starting up systemd.

To work around this issue I had to specify chroot_mounts in the packer config file to un-include the /etc/resolv.conf bind, then add additional_chroot_mounts to bind /run/systemd from the host.

{
  "variables": {
  },
  "builders": [{
    "type": "arm-image",
    "qemu_binary": "qemu-aarch64-static",
    "image_type": "raspberrypi",
    "chroot_mounts": [
      ["proc", "proc", "/proc"],
      ["sysfs", "sysfs", "/sys"],
      ["bind", "/dev", "/dev"],
      ["devpts", "devpts", "/dev/pts"],
      ["binfmt_misc", "binfmt_misc", "/proc/sys/fs/binfmt_misc"]
    ],
    "additional_chroot_mounts": [
      ["bind", "/run/systemd", "/run/systemd"]
    ],
    "iso_url": "http://cdimage.ubuntu.com/releases/18.04.4/release/ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz",
    "iso_checksum_type": "sha256",
    "iso_checksum": "f270d4a11fcef7f85ea77bc0642d1c6db2666ae734e9dcc4cb875a31c9f0dc57"
  }],
  "provisioners": [{
    "type": "shell",
    "inline": [
      "apt-get update",
    ]
  }]
}

I think it would be helpful to check for systemd in order to default to the /run/systemd chroot mount. If that directory doesn't exist, then I think it's safe to say we're using a sysvinit system and can use the existing /etc/resolv.conf bind. Of course, this will only work so long as the host VM in vagrant or docker is a systemd host.

[micchickenburger]

Related to pull request #50

[yuval-k]

not too familiar with this, how would you check for systemd? do your have a heuristic in mind?

[micchickenburger]

I think it would be fine to just check for the /run/systemd directory. If that directory exists I think it's safe to assume the system uses systemd instead of sysvinit.

[hoshsadiq]

Presuming this isn't just images based on systemd. You could potentially have a base image that already puts the correct file there (e.g. by installing dnsmasq or whatnot). In my opinion that file should either be mounted defensively or the mount should explicitly be enabled through an option rather than by default. Having resolv.conf mounted is a network/host specific use case.

[rgl]

I've tried your workaround with ubuntu 20.04 guest (on a ubuntu 20.04 host with packer-builder-arm-image 0.1.4.5 and packer 1.5.6) and it seems to work, but when I try to execute the shell provisioner with:

"provisioners": [
    {
      "type": "shell",
      "execute_command": "bash {{ .Path }}",
      "script": "provision.sh"
    }
  ]

It errors out with (no mater what I put in execute_command (or even if I remove it), it never executes bash):

==> arm-image: Provisioning with shell script: provision.sh
==> arm-image: chroot: failed to run command ‘/bin/sh’: No such file or directory

Using an "inline": "uname" also fails with the same error.

Do you have any clue of what is going on?

[yuval-k]

closing as fixed by #70