Bug#854400: systemd: FTBFS if /tmp is an overlayfs
Control: forwarded -1 https://github.com/systemd/systemd/pull/6656 On Mon, 06 Feb 2017, James Cowgill wrote: > > I think this is a bug in overlayfs. > > Well it's the documented behavior of overlayfs which others have > probably relied on, so I think it's very unlikely overlayfs will be > changed now. Actually it seems to have changed in Linux 4.12 and the uptsream documentation at https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt now also says this: | In the special case of all overlay layers on the same underlying | filesystem, all objects will report an st_dev from the overlay | filesystem and st_ino from the underlying filesystem. This will | make the overlay mount more compliant with filesystem scanners and | overlay objects will be distinguishable from the corresponding | objects in the original filesystem. That said this bug is still rather annoying and I would like to see it fixed, so I created a pull request upstream: https://github.com/systemd/systemd/pull/6656 Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#854400: systemd: FTBFS if /tmp is an overlayfs
Hi, On 06/02/17 17:36, Michael Biebl wrote: > Am 06.02.2017 um 18:07 schrieb James Cowgill: >> 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 > > I think this is a bug in overlayfs. Well it's the documented behavior of overlayfs which others have probably relied on, so I think it's very unlikely overlayfs will be changed now. James signature.asc Description: OpenPGP digital signature
Bug#854400: systemd: FTBFS if /tmp is an overlayfs
Am 06.02.2017 um 18:07 schrieb James Cowgill: > 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 > I think this is a bug in overlayfs. -- 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#854400: systemd: FTBFS if /tmp is an overlayfs
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
