The filesystem overlay is a tree that is copied over the target fs after building everything - which is currently usually done in the post-build script. [Peter: don't ignore missing directories] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
58 lines
2.9 KiB
Plaintext
58 lines
2.9 KiB
Plaintext
// -*- mode:doc -*- ;
|
|
|
|
[[rootfs-custom]]
|
|
Customizing the generated target filesystem
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Besides changing one or another configuration through +make *config+,
|
|
there are a few ways to customize the resulting target filesystem.
|
|
|
|
* Customize the target filesystem directly and rebuild the image. The
|
|
target filesystem is available under +output/target/+. You can
|
|
simply make your changes here and run make afterwards - this will
|
|
rebuild the target filesystem image. This method allows you to do
|
|
anything to the target filesystem, but if you decide to completely
|
|
rebuild your toolchain and tools, these changes will be lost.
|
|
_Changes do not survive the +make clean+ command_.
|
|
|
|
* Create your own 'target skeleton'. You can start with the default
|
|
skeleton available under +system/skeleton+ and then customize it to
|
|
suit your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and
|
|
+BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the
|
|
location of your custom skeleton. These options can be found in the
|
|
+System configuration+ menu. At build time, the contents of the
|
|
skeleton are copied to output/target before any package
|
|
installation.
|
|
|
|
* Create a filesystem overlay: a tree of files that are copied directly
|
|
over the target filesystem after it has been built. Set
|
|
+BR2_ROOTFS_OVERLAY+ to the top of the tree. +.git+, +.svn+,
|
|
+.hg+ directories and files ending with +~+ are excluded.
|
|
_Among these first 3 methods, this one should be preferred_.
|
|
|
|
* In the Buildroot configuration, you can specify the path to a
|
|
*post-build script*, that gets called 'after' Buildroot builds all the
|
|
selected software, but 'before' the rootfs packages are
|
|
assembled. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ will allow you to
|
|
specify the location of your post-build script. This option can be
|
|
found in the +System configuration+ menu. The destination root
|
|
filesystem folder is given as the first argument to this script,
|
|
and this script can then be used to remove or modify any file in your
|
|
target filesystem. You should, however, use this feature with care.
|
|
Whenever you find that a certain package generates wrong or unneeded
|
|
files, you should fix that package rather than work around it with a
|
|
post-build cleanup script.
|
|
You may also use these variables in your post-build script:
|
|
- +BUILDROOT_CONFIG+: the path to the Buildroot .config file
|
|
- +HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+: see
|
|
xref:generic-package-reference[]
|
|
- +BINARIES_DIR+: the place where all binary files (aka images) are
|
|
stored
|
|
- +BASE_DIR+: the base output directory
|
|
|
|
* A special package, 'customize', stored in +package/customize+ can be
|
|
used. You can put all the files that you want to see in the final
|
|
target root filesystem in +package/customize/source+, and then
|
|
enable this special package in the configuration system. _This
|
|
method is marked as deprecated_.
|