summaryrefslogtreecommitdiffstats
path: root/docs/manual/customize-rootfs.txt
blob: a1a556b85cb09afb66332826cae6697d77b5beca (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// -*- 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.

* 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 copy programs, static data or
  any other needed file to 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. _Among these first 3 methods, this one should be preferred_.

* 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_.