Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Michael Biebl]

Control: reassign -1 sbuild

Am 18.02.2020 um 21:52 schrieb Jörg Frings-Fürst:
> Hi,
> 
> I have the same issue:
> 
> 
> Build a new chroot with:
> 
> sudo sbuild-createchroot --include=eatmydata,ccache,gnupg --make-sbuild-tarball=/var/cache/chroot/sid1-amd64-sbuild.tar.gz sid `mktemp -d` http://deb.debian.org/debian
> 
> 
> The I build simple-scan/3.34.4-1
> 
> [quote]
> Selecting previously unselected package sbuild-build-depends-dose3-dummy.
> Preparing to unpack .../8-sbuild-build-depends-dose3-dummy_0.invalid.0_amd64.deb ...
> Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ...
> Setting up systemd (244.3-1) ...
> Detected unsafe path transition / → /var during canonicalization of /var/log/journal.
> Detected unsafe path transition / → /var during canonicalization of /var/log/journal.
> Detected unsafe path transition / → /var during canonicalization of /var/log/journal.
> Detected unsafe path transition / → /var during canonicalization of /var/log/journal.

That's a slightly different issue.
Here / and /var have different permissions.
In the original bug report it was /var and /var/log

> dpkg: error processing package systemd (--configure):
>  installed systemd package post-installation script subprocess returned error exit status 73
> [/quote]
> 
> The same parts from build simple-scan/
> [qoute]
> Setting up libcryptsetup12:amd64 (2:2.2.2-1) ...
> Setting up systemd (244-3) ...
> Created symlink /etc/systemd/system/getty.target.wants/getty at tty1.service → /lib/systemd/system/getty at .service.
> Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → /lib/systemd/system/remote-fs.target.
> Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /lib/systemd/system/systemd-timesyncd.service.
> Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.
> Initializing machine ID from random generator.
> [/quote]

If you can still reproduce this with a current version of sbuild, let's
reassign the bug then.

If I understood Johannes correctly, /var (and /) is not supposed to be
owned by sbuild or have otherwise messed up permissions.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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