Package: debos
Version: 1.0.0+git20210707.c66a48d-2+b2
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: dai...@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 busybox1:1.35.0-2
ii debootstrap1.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-x861: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 zip3.0-12
debos suggests no packages.
-- no debconf information
