Your message dated Sat, 24 Mar 2018 21:47:51 +0100
with message-id <5a21ca04-4b83-62a0-86d0-eb3c7b55e...@debian.org>
and subject line Re: Bug#876103: systemd-nspawn: --read-only is broken
has caused the Debian Bug report #876103,
regarding systemd-nspawn: --read-only is broken
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
876103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876103
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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 libblkid1 2.29.2-1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.24-11+deb9u1
ii libcurl3-gnutls 7.52.1-5
ii libgcrypt20 1.7.6-2+deb9u2
ii libip4tc0 1.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-progs 4.7.3-1
ii libnss-mymachines 232-25+deb9u1
systemd-container suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Lauri,
On Mon, 4 Dec 2017 09:29:17 +0200 Lauri Tirkkonen <la...@tuxera.com> wrote:
> 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.
I thought about this a bit more, and I think those particular changes
are a bit out of scope for a stable upload.
As said, we do provide backports of newer versions, so if this
particular feature is important to you, please consider using those.
Sorry,
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
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
