Go to file
Yann E. MORIN 409d4c3fe9 fs: don't use an intermediate tarball
Since 118534fe54 (fs: use a common tarball as base for the other
filesystems), the filesystem creation is split in two steps, using an
intermediate tarball to carry the generic, common finalisations to the
per-filesystem finalisation and image creation.

However, this intermediate tarball causes an issue with capabilities:
they are entirely missing in the generated filesystems.

Capabilities are stored in the extended attribute security.capability,
which tar by default will not store/restore, unless explicitly told to,
e.g. with --xattrs-include='*', which we don't pass.

Now, passing this option when creating and extracting the intermediate
tarball, both done under fakeroot, will cause fakeroot to report an
invalid filetype for files with capabilities. mksquashfs would report
such unknown files as a warning, while mkfs.ext2 would fail (with a
similar error message), e.g.:

    File [...]/usr/sbin/getcap has unrecognised filetype 0, ignoring

This is due to a poor interaction between tar and fakeroot; running as
root the exact same commands we run under fakeroot, works as expected.
Unfortunately, short of fixing fakeroot (which would first require
understanding the problem in there), we don't have much options.

The intermediate tarball was made to avoid redoing the same actions over
and over again for each filesystem to build. However, most of the time,
only one or two such filesystems would be enabled [0], and those actions
are usually pretty lightweight. So, using an intermediate tarball does
not provide a big optimisation.

The main reason to introduce the intermediate tarball, however, is that
it allows to postpone per-filesystem finalisations to be applied only
for the corresponding filesystem, not for all of them.

So, we get rid of the intermediate tarball, and simply move all of the
code to run under fakeroot to the per-filesystem fakeroot script.
Instead of extracting the intermediate tarball, we just rsync the
original target/ directory, and apply the filesystem finalisations on
that copy. The only thing still done in the rootfs-common step is to
generate the intermediate files (users file, devices file) that are used
in the fakeroot script.

Fixes: https://bugs.busybox.net/show_bug.cgi?id=11216

Note: an alternate solution would have been to keep the intermediate
tarball to keep most of the common finalisations, and move only the
permissions to each filesystem, but that was getting a bit more complex
and changed the ordering of permissions and post-fakeroot scripts. Once
we bite the bullet of having some common finalisation done in each
filesystem, it's easier to just move all of them.

[0] Most probsably, users would enable the real filesystem to put on
their device, plus the 'tar' filesystem, to be able to easily inspect
the content on their development machine.

Reported-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2018-11-13 00:47:36 +01:00
arch arch: drop BR2_GCC_TARGET_CPU_REVISION option 2018-10-01 14:52:32 +02:00
board configs/amarula_a64_relic: add WiFi support 2018-11-01 14:21:32 +01:00
boot uboot: bump to version 2018.09 2018-11-03 15:54:19 +01:00
configs configs/amarula_a64_relic: add WiFi support 2018-11-01 14:21:32 +01:00
docs docs/website/news.html: update for 2018.11-rc1 2018-11-10 00:12:52 +01:00
fs fs: don't use an intermediate tarball 2018-11-13 00:47:36 +01:00
linux {linux, linux-headers}: bump 4.{4, 9, 14, 18}.x series 2018-11-11 22:11:04 +01:00
package gstreamer1: fix riscv64 compile 2018-11-13 00:08:27 +01:00
support fs: don't use an intermediate tarball 2018-11-13 00:47:36 +01:00
system system: update Config.in comment about systemd dependencies 2018-09-15 00:05:48 +02:00
toolchain toolchain/toolchain-buildroot: enable glibc for all little-endian ARCs with atomic ops 2018-11-09 22:02:16 +01:00
utils utils/scanpypi: use archive file name to specify the extraction folder 2018-11-02 21:35:08 +01:00
.defconfig arch: remove support for sh64 2016-09-08 22:15:15 +02:00
.flake8 .flake8: ignore utils/diffconfig 2018-03-13 22:37:54 +01:00
.gitignore update gitignore 2013-05-04 12:41:55 +02:00
.gitlab-ci.yml .gitlab-ci.yml: update after addition of TestF2FS test case 2018-11-08 22:41:53 +01:00
.gitlab-ci.yml.in .gitlab-ci.yml: do runtime tests only on explicit trigger 2018-10-21 23:34:18 +02:00
CHANGES Update for 2018.11-rc1 2018-11-09 22:56:48 +01:00
Config.in Config.in: security hardening: disable FORTIFY_SOURCE for gcc < 6 2018-11-06 08:54:25 +01:00
Config.in.legacy boot/xloader: remove package 2018-10-26 16:59:05 +02:00
COPYING COPYING: add exception about patch licensing 2016-02-26 19:50:13 +01:00
DEVELOPERS ell: new package 2018-11-08 21:39:57 +01:00
Makefile Update for 2018.11-rc1 2018-11-09 22:56:48 +01:00
Makefile.legacy Remove BR2_DEPRECATED 2016-10-15 23:14:45 +02:00
README README: add reference to submitting-patches 2016-02-01 19:16:08 +01:00

Buildroot is a simple, efficient and easy-to-use tool to generate embedded
Linux systems through cross-compilation.

The documentation can be found in docs/manual. You can generate a text
document with 'make manual-text' and read output/docs/manual/manual.text.
Online documentation can be found at http://buildroot.org/docs.html

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the target architecture and the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) find the kernel, bootloader, root filesystem, etc. in output/images

You do not need to be root to build or run buildroot.  Have fun!

Buildroot comes with a basic configuration for a number of boards. Run
'make list-defconfigs' to view the list of provided configurations.

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org
You can also find us on #buildroot on Freenode IRC.

If you would like to contribute patches, please read
https://buildroot.org/manual.html#submitting-patches