Your message dated Fri, 16 Nov 2018 01:06:53 +0100
with message-id <[email protected]>
and subject line Re: systemd: FTBFS if /tmp is an overlayfs
has caused the Debian Bug report #854400,
regarding systemd: FTBFS if /tmp is an overlayfs
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 [email protected]
immediately.)
--
854400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854400
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: systemd
Version: 232-15
Severity: important
Hi,
While testing #852811 I discovered that systemd does not build within an
overlayfs schroot (which all my mips chroots are setup as). Specifically
the "test-copy" test fails with:
> FAIL: test-copy
> ===============
>
> test_copy_file
> test_copy_file_fd
> test_copy_tree
> Assertion 'access(f, F_OK) == 0' failed at ../src/test/test-copy.c:136,
> function test_copy_tree(). Aborting.
> FAIL test-copy (exit status: 134)
The assertion is caused by a file not being copied by copy_tree and that
is in turn caused by this line:
https://sources.debian.net/src/systemd/232-15/src/basic/copy.c/#L342
The above line does not copy files if the device of the file is not the
same as the device of the parent directory, however on an overlayfs
filesystem this is condition is always true for non-directories.
From https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt:
> This approach is 'hybrid' because the objects that appear in the
> filesystem do not all appear to belong to that filesystem. In many
> cases an object accessed in the union will be indistinguishable
> from accessing the corresponding object from the original filesystem.
> This is most obvious from the 'st_dev' field returned by stat(2).
>
> While directories will report an st_dev from the overlay-filesystem,
> all non-directory objects will report an st_dev from the lower or
> upper filesystem that is providing the object. Similarly st_ino will
> only be unique when combined with st_dev, and both of these can change
> over the lifetime of a non-directory object. Many applications and
> tools ignore these values and will not be affected.
Note that this behavior is different from say 'cp -Rx'. cp only checks
the value of st_dev if the file is a directory. This allows it to work
correctly with overlayfs.
http://sources.debian.net/src/coreutils/8.26-2/src/copy.c/?hl=2547#L2547
Thanks,
James
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
On Mon, 6 Feb 2017 17:07:37 +0000 James Cowgill <[email protected]> wrote:
> Source: systemd
> Version: 232-15
> Severity: important
>
> Hi,
>
> While testing #852811 I discovered that systemd does not build within an
> overlayfs schroot (which all my mips chroots are setup as). Specifically
> the "test-copy" test fails with:
>
> > FAIL: test-copy
> > ===============
> >
> > test_copy_file
> > test_copy_file_fd
> > test_copy_tree
> > Assertion 'access(f, F_OK) == 0' failed at ../src/test/test-copy.c:136,
> > function test_copy_tree(). Aborting.
> > FAIL test-copy (exit status: 134)
>
> The assertion is caused by a file not being copied by copy_tree and that
> is in turn caused by this line:
> https://sources.debian.net/src/systemd/232-15/src/basic/copy.c/#L342
>
> The above line does not copy files if the device of the file is not the
> same as the device of the parent directory, however on an overlayfs
> filesystem this is condition is always true for non-directories.
>
> From https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt:
> > This approach is 'hybrid' because the objects that appear in the
> > filesystem do not all appear to belong to that filesystem. In many
> > cases an object accessed in the union will be indistinguishable
> > from accessing the corresponding object from the original filesystem.
> > This is most obvious from the 'st_dev' field returned by stat(2).
> >
> > While directories will report an st_dev from the overlay-filesystem,
> > all non-directory objects will report an st_dev from the lower or
> > upper filesystem that is providing the object. Similarly st_ino will
> > only be unique when combined with st_dev, and both of these can change
> > over the lifetime of a non-directory object. Many applications and
> > tools ignore these values and will not be affected.
>
> Note that this behavior is different from say 'cp -Rx'. cp only checks
> the value of st_dev if the file is a directory. This allows it to work
> correctly with overlayfs.
> http://sources.debian.net/src/coreutils/8.26-2/src/copy.c/?hl=2547#L2547
>
Upstream rejected https://github.com/systemd/systemd/pull/6656, so I'm
closing this bug report as wontfix as we don't plan to ship a distro
specific patch for this issue.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
--- End Message ---
