[pkg-go] Bug#1020288: debos: unable to resolve host address

[Arnaud Rebillout]

Package: debos
Version: 1.0.0+git20210707.c66a48d-2+b2
Severity: important
User: devel at kali.org
Usertags: origin-kali
X-Debbugs-Cc: daissi at debian.org

Dear Maintainer,

at the moment debos (and fakemachine) is broken in unstable:

~~~~
$ cat debootstrap.yaml
architecture: amd64

actions:
  - action: debootstrap
    suite: stable

$ debos debootstrap.yaml
Running /debos --artifactdir /home/arno/kali/proj/vm-images/kali-vm/tmp /home/arno/kali/proj/vm-images/kali-vm/tmp/debootstrap.yaml using kvm backend
2022/09/19 10:49:09 ==== debootstrap ====
2022/09/19 10:49:09 Debootstrap | W: Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory)
2022/09/19 10:49:09 Debootstrap | W: Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory)
2022/09/19 10:49:09 Debootstrap | I: Target architecture can be executed
2022/09/19 10:49:09 Debootstrap | I: Retrieving InRelease
2022/09/19 10:49:09 Debootstrap | I: Retrieving Release
2022/09/19 10:49:09 Debootstrap | E: Failed getting release file http://deb.debian.org/debian/dists/stable/Release
2022/09/19 10:49:09 debootstrap.log | amd64: ok
2022/09/19 10:49:09 debootstrap.log | wget: unable to resolve host address 'deb.debian.org'
2022/09/19 10:49:09 debootstrap.log | wget: unable to resolve host address 'deb.debian.org'
2022/09/19 10:49:09 Action `debootstrap` failed at stage Run, error: exit status 1
Powering off.
~~~~

Hostname resolution broke because systemd-resolved was split out of the
systemd package, and now it lives in its own package systemd-resolved. 
On my system, systemd-resolved is not installed, hence the failure 
above. Apparently systemd-resolved is mandatory for the kvm backend?
What about the uml backend?

At a first glance, it seems that debos (and fakemachine) should now 
Depend on systemd-resolved. However it's a bit more complicated.

Installing the package systemd-resolved has MAJOR consequences:
- the postinst script will remove /etc/resolv.conf, and replace it with
  a symlink to ../run/systemd/resolve/stub-resolv.conf
- the service systemd-resolved will be enabled

This behavior makes sense when a user manually installs systemd-resolved
(because they want to use it for name resolution). But when installing
debos, enabling name resolution via systemd-resolved at the same time is
surely an unintended (and unexpected) effect.

I don't know how to handle that. I don't know if it would be possible to
rework the systemd-resolved package and split it, so that it's possible
to install the binaries, without actually enabling it. Maybe we should
ask the systemd maintainer, but I wanted to get your impression first.

Thanks!

Arnaud

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debos depends on:
ii  busybox            1:1.35.0-2
ii  debootstrap        1.0.127
ii  libc6              2.34-7
ii  libglib2.0-0       2.73.3-3
ii  libostree-1-1      2022.5-3
ii  qemu-system-x86    1:7.0+dfsg-7+b1
ii  qemu-user-static   1:7.0+dfsg-7+b1
ii  systemd-container  251.4-3

Versions of packages debos recommends:
ii  bmap-tools         3.6-1
ii  bzip2              1.0.8-5
ii  e2fsprogs          1.46.5-2
ii  linux-image-amd64  5.19.6-1
ii  mount              2.38.1-1
ii  ovmf               2022.05-4
ii  parted             3.5-1
ii  udev               251.4-3
ii  xz-utils           5.2.5-2.1
ii  zip                3.0-12

debos suggests no packages.

-- no debconf information