On Sat, 20 Aug 2022 20:30:43 +0100 Luca Boccassi <bl...@debian.org> wrote: > On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop <m...@debian.org> > wrote: > > Hi, > > > > * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]: > > > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote: > > > > > > And, last but not the least, I see that /etc/resolv.conf is now > part of > > > > systemd-resolved files, which means that it would be deleted when > the > > > > systemd-resolved package is removed from the system. I think it > would > > > > also deserve its own bug with some high priority > > > > > > No, that's working as intended - you remove one resolver, you need > to > > > install another one that provides it. > > > > I just tested a few things, JFYI: > > > > * When systemd-resolved is installed and gets removed, the > > file/symlink /etc/resolv.conf gets removed as well. Is that really > > expected? (This is something e.g. the resolvconf doesn't do, you > > still end up with a /etc/resolv.conf being in-place then) > > > > * Installation of the systemd-resolved package inside docker/podman > > fails hard for me (running on a Debian/bullseye host): > > > > | Unpacking systemd-resolved (251.4-1) ... > > | dpkg: error processing archive /var/cache/apt/archives/systemd- > resolved_251.4-1_amd64.deb (--unpack): > > | unable to make backup link of './etc/resolv.conf' before > installing new version: Invalid cross-device link > > | Selecting previously unselected package libnss-resolve:amd64. > > | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ... > > | Unpacking libnss-resolve:amd64 (251.4-1) ... > > | Errors were encountered while processing: > > | /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb > > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > (Didn't investigate further on this yet, seems to be related to the > > way dpkg handles symlinks (as set up by dh_link in the systemd > > packaging) and containers with overlay doesn't like that, though > > installing systemd inside docker/podman containers used to work fine > > so far for me) > > > > HTH && regards > > -mika- > > Yes I noticed the same thing when building images, this cross-device > check is a true annoyance and can't seem to find a workaround :-/
I can't find a solution, so unfortunately it looks like we have to resort to maintainer scripts, which is awful but I can't think of anything else: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164 -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part