Bug#939904: Temporary network disruption during upgrade

Luca Boccassi bluca at debian.org
Sat Aug 20 23:41:02 BST 2022


On Sat, 20 Aug 2022 20:30:43 +0100 Luca Boccassi <bluca at debian.org>
wrote:
> On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop <mika at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220820/d3e56a24/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list