Bug#939904: Temporary network disruption during upgrade

[Michael Prokop]

Hi,

* Michael Biebl [Fri Aug 19, 2022 at 09:11:47AM +0200]:
> Am 19.08.22 um 08:58 schrieb Michael Prokop:

> > 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?

Yeah, good question. :) That's a problem resolvconf doesn't seem to
have AFAICT (as you're usually configuring specific nameservers
there, and resolvconf can continue to restore/keep them in case of
uninstalling resolvconf). But given that "it's usually a DNS
problem" this situation is something which we should probably keep
in mind.

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

AFAIK no:

| root at 5880f837612b:/# mount
| fuse-overlayfs on / type fuse.fuse-overlayfs (rw,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
| proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
| tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755,uid=1000,gid=1000)
| sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
| devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=100004,mode=620,ptmxmode=666)
| mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
| tmpfs on /etc/resolv.conf type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000)
| tmpfs on /etc/hosts type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000)
| shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=64000k,uid=1000,gid=1000)
| tmpfs on /etc/hostname type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000)
| tmpfs on /run/.containerenv type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000)
| cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec,relatime)
| udev on /dev/null type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /dev/zero type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /dev/full type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /dev/tty type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /dev/random type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /dev/urandom type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| tmpfs on /proc/acpi type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000)
| udev on /proc/kcore type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /proc/keys type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /proc/timer_list type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| udev on /proc/sched_debug type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755)
| tmpfs on /sys/firmware type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000)
| tmpfs on /sys/dev/block type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000)
| proc on /proc/asound type proc (ro,relatime)
| proc on /proc/bus type proc (ro,relatime)
| proc on /proc/fs type proc (ro,relatime)
| proc on /proc/irq type proc (ro,relatime)
| proc on /proc/sys type proc (ro,relatime)
| proc on /proc/sysrq-trigger type proc (ro,relatime)

But podman and docker both by default use the resolv.conf bind
mount, e.g. when inspecting the podman container one can see:

| ResolvConfPath": "/run/user/1000/containers/overlay-containers/5880f837612b91c1d3a53d5886993cdaae36c78e70633121f628cc89759b7067/userdata/resolv.conf",

(see also `tmpfs on /etc/resolv.conf type tmpfs` in mount output above).

podman here™ uses the overlay (fuse) driver, but also running a
docker container with overlay2 instead doesn't change this problem,
inspecting the container also shows:

| "ResolvConfPath": "/var/lib/docker/containers/5f67361c24dfd4807b360263f546acbddfe70777e34c811987feec239f7a6cfb/resolv.conf",

... and its mount output is similar (though not identical due to
different internal behaviors):

| root at 5f67361c24df:/# mount
| overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/MSJTD4IGM2UVJIF2PRZU3X2UG4:/var/lib/docker/overlay2/l/BDJL4S6XH3QHLIEI74CGOEPXWH,upperdir=/var/lib/docker/overlay2/f2a3281e02c6e9fb0e5478bc3b948a1aa04f7c34bb6ccf94be4ca4641e768dff/diff,workdir=/var/lib/docker/overlay2/f2a3281e02c6e9fb0e5478bc3b948a1aa04f7c34bb6ccf94be4ca4641e768dff/work)
| proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
| tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
| devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
| sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
| cgroup on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec,relatime)
| mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
| shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
| /dev/mapper/crypt_lunge-docker on /etc/resolv.conf type ext4 (rw,relatime)
| /dev/mapper/crypt_lunge-docker on /etc/hostname type ext4 (rw,relatime)
| /dev/mapper/crypt_lunge-docker on /etc/hosts type ext4 (rw,relatime)
| devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
| proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
| proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
| proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
| proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
| proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
| tmpfs on /proc/asound type tmpfs (ro,relatime)
| tmpfs on /proc/acpi type tmpfs (ro,relatime)
| tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
| tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
| tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
| tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
| tmpfs on /sys/firmware type tmpfs (ro,relatime)

HTH && regards
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220819/141fa5f9/attachment.sig>