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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220819/33c2366a/attachment.sig>