Re: Bug#939904: Temporary network disruption during upgrade

[Michael Biebl]

Hi

Am 19.08.22 um 08:58 schrieb Michael Prokop:

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)

The question would be, which file should be restored.

One could make a copy of the resolv.conf file when systemd-resolved is installed and restore that file upon removal. But how would you know if the resolv.conf is still valid (after say a year)? Isn't it cleaner to simply do nothing here and fail hard?

* 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)

Is /run bind-mounted into the container somehow?

OpenPGP_signature
Description: OpenPGP digital signature