Bug#876103: systemd-nspawn: --read-only is broken
Hi, On Sun, Dec 03 2017 13:47:29 +0100, Michael Biebl wrote: > > There is an upstream fix for this in > > https://github.com/systemd/systemd/pull/4693 -- > > acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually > > fixes read-only containers, but it requires two other commits to apply > > cleanly. I applied the following sequence to systemd-container on > > stretch: > > > > https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d > > https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e > > https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b > > > > and it solved my problem. Could you backport these patches to stretch? > > > > Those patches looks a bit invasive for a stretch stable upload. > But we do provide updated systemd versions with this fix via > stretch-backports: > https://packages.debian.org/source/stable-backports/systemd > > Would that be sufficient for your case? It turned out that we needed a couple other patches for systemd-container, including one yet to be released, so for our case it's sufficient to do nothing since we now use our own systemd-container package :) However, I don't think the patches I listed are that invasive -- note that they only affect the systemd-nspawn binary. Anyone else having a problem with --read-only can move to the backports package, yes, but we explicitly did not want to upgrade all of systemd just to get a few patches to nspawn.
Bug#876103: systemd-nspawn: --read-only is broken
Am 18.09.2017 um 15:43 schrieb Lauri Tirkkonen: > Package: systemd-container > Version: 232-25+deb9u1 > Severity: normal > > Dear Maintainer, > > on stretch, 'systemd-nspawn --read-only' fails to start the container > entirely. Trivial test case: > > # machinectl pull-tar > https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz > [ output omitted ] > # systemd-nspawn -M xenial-server-cloudimg-amd64-root -- true > # systemd-nspawn -M xenial-server-cloudimg-amd64-root --read-only -- true > Spawning container xenial-server-cloudimg-amd64-root on > /var/lib/machines/xenial-server-cloudimg-amd64-root. > Press ^] three times within 1s to kill container. > Failed to create directory > /var/lib/machines/xenial-server-cloudimg-amd64-root/sys: Read-only file system > > (the first systemd-nspawn call is there to implicitly create some > directories inside the container root that must exist for read-only to > work) > > The expected behavior is that 'true' is executed in container and exit > status 0 is returned; however, the container is not started and the exit > status is 1. > > There is an upstream fix for this in > https://github.com/systemd/systemd/pull/4693 -- > acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually > fixes read-only containers, but it requires two other commits to apply > cleanly. I applied the following sequence to systemd-container on > stretch: > > https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d > https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e > https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b > > and it solved my problem. Could you backport these patches to stretch? > Those patches looks a bit invasive for a stretch stable upload. But we do provide updated systemd versions with this fix via stretch-backports: https://packages.debian.org/source/stable-backports/systemd Would that be sufficient for your case? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#876103: systemd-nspawn: --read-only is broken
Package: systemd-container Version: 232-25+deb9u1 Severity: normal Dear Maintainer, on stretch, 'systemd-nspawn --read-only' fails to start the container entirely. Trivial test case: # machinectl pull-tar https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz [ output omitted ] # systemd-nspawn -M xenial-server-cloudimg-amd64-root -- true # systemd-nspawn -M xenial-server-cloudimg-amd64-root --read-only -- true Spawning container xenial-server-cloudimg-amd64-root on /var/lib/machines/xenial-server-cloudimg-amd64-root. Press ^] three times within 1s to kill container. Failed to create directory /var/lib/machines/xenial-server-cloudimg-amd64-root/sys: Read-only file system (the first systemd-nspawn call is there to implicitly create some directories inside the container root that must exist for read-only to work) The expected behavior is that 'true' is executed in container and exit status 0 is returned; however, the container is not started and the exit status is 1. There is an upstream fix for this in https://github.com/systemd/systemd/pull/4693 -- acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually fixes read-only containers, but it requires two other commits to apply cleanly. I applied the following sequence to systemd-container on stretch: https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b and it solved my problem. Could you backport these patches to stretch? -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-container depends on: ii dbus 1.10.18-1 ii libacl1 2.2.52-3+b1 ii libblkid12.29.2-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u1 ii libcurl3-gnutls 7.52.1-5 ii libgcrypt20 1.7.6-2+deb9u2 ii libip4tc01.6.0+snapshot20161117-6 ii liblzma5 5.2.2-1.2+b1 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii systemd 232-25+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages systemd-container recommends: ii btrfs-progs4.7.3-1 ii libnss-mymachines 232-25+deb9u1 systemd-container suggests no packages. -- no debconf information
