On Sun, 2021-10-24 at 23:49 +0200, Thomas Goirand wrote: > I agree this should be fixed in Stable. I've uploaded the fix to > unstable already. However, I'm not sure why oldstable should be > updated. Can you share your view? I forgot why I thought it should be fixed before bullseye, so I have taken a look at the code. The function generate_sources_list takes the codename to generate for as an argument, so it needs to DTRT no matter what the codename is, but then apply_apt only passes lsb_release results to it, but then lsb_release can be run in a chroot via the target parameter, but then the cloud-init subp subprocess wrapper errors if the target parameter is set, but the (unused) external subp module does not error if the target parameter is set and c-i subp later still supports using the target parameter to chroot into a directory. So it looks like cloud-init in sid at least is designed to be able to deal with a chroot, which would mean that generate_sources_list needs to generate a different sources.list depending on the codename, which could be different to the host codename, but in practice the subp function blocks using a chroot to get dpkg/apt info. I suggest you investigate if the chroot functionality works in all the releases of cloud-init in Debian and if it works in any of them, then backport the patch you added to those releases. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part