6b13f685e
 김민수
BSP 최초 추가
|
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
[[rootfs-custom]]
=== Customizing the generated target filesystem
Besides changing the configuration through +make *config+,
there are a few other ways to customize the resulting target filesystem.
The two recommended methods, which can co-exist, are root filesystem
overlay(s) and post build script(s).
Root filesystem overlays (+BR2_ROOTFS_OVERLAY+)::
+
A filesystem overlay is a tree of files that is copied directly
over the target filesystem after it has been built. To enable this
feature, set config option +BR2_ROOTFS_OVERLAY+ (in the +System
configuration+ menu) to the root of the overlay. You can even specify
multiple overlays, space-separated. If you specify a relative path,
it will be relative to the root of the Buildroot tree. Hidden
directories of version control systems, like +.git+, +.svn+, +.hg+,
etc., files called +.empty+ and files ending in +~+ are excluded from
the copy.
+
As shown in xref:customize-dir-structure[], the recommended path for
this overlay is +board/<company>/<boardname>/rootfs-overlay+.
Post-build scripts (+BR2_ROOTFS_POST_BUILD_SCRIPT+)::
+
Post-build scripts are shell scripts called 'after' Buildroot builds
all the selected software, but 'before' the rootfs images are
assembled. To enable this feature, specify a space-separated list of
post-build scripts in config option +BR2_ROOTFS_POST_BUILD_SCRIPT+ (in
the +System configuration+ menu). If you specify a relative path, it
will be relative to the root of the Buildroot tree.
+
Using post-build scripts, you can 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 some
post-build cleanup scripts.
+
As shown in xref:customize-dir-structure[], the recommended path for
this script is +board/<company>/<boardname>/post_build.sh+.
+
The post-build scripts are run with the main Buildroot tree as current
working directory. The path to the target filesystem is passed as the
first argument to each script. If the config option
+BR2_ROOTFS_POST_SCRIPT_ARGS+ is not empty, these arguments will be
passed to the script too. All the scripts will be passed the exact
same set of arguments, it is not possible to pass different sets of
arguments to each script.
+
In addition, you may also use these environment variables:
- +BR2_CONFIG+: the path to the Buildroot .config file
- +HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+: see
xref:generic-package-reference[]
- +BUILD_DIR+: the directory where packages are extracted and built
- +BINARIES_DIR+: the place where all binary files (aka images) are
stored
- +BASE_DIR+: the base output directory
Below three more methods of customizing the target filesystem are
described, but they are not recommended.
Direct modification of the target filesystem::
+
For temporary modifications, you can modify the target filesystem
directly and rebuild the image. The target filesystem is available
under +output/target/+. After making your changes, run +make+ to
rebuild the target filesystem image.
+
This method allows you to do anything to the target filesystem, but if
you need to clean your Buildroot tree using +make clean+, these
changes will be lost. Such cleaning is necessary in several cases,
refer to xref:full-rebuild[] for details. This solution is therefore
only useful for quick tests: _changes do not survive the +make clean+
command_. Once you have validated your changes, you should make sure
that they will persist after a +make clean+, using a root filesystem
overlay or a post-build script.
Custom target skeleton (+BR2_ROOTFS_SKELETON_CUSTOM+)::
+
The root filesystem image is created from a target skeleton, on top of
which all packages install their files. The skeleton is copied to the
target directory +output/target+ before any package is built and
installed. The default target skeleton provides the standard Unix
filesystem layout and some basic init scripts and configuration files.
+
If the default skeleton (available under +system/skeleton+) does not
match your needs, you would typically use a root filesystem overlay or
post-build script to adapt it. However, if the default skeleton is
entirely different than what you need, using a custom skeleton may be
more suitable.
+
To enable this feature, enable config option
+BR2_ROOTFS_SKELETON_CUSTOM+ and set +BR2_ROOTFS_SKELETON_CUSTOM_PATH+
to the path of your custom skeleton. Both options are available in the
+System configuration+ menu. If you specify a relative path, it will
be relative to the root of the Buildroot tree.
+
This method is not recommended because it duplicates the entire
skeleton, which prevents taking advantage of the fixes or improvements
brought to the default skeleton in later Buildroot releases.
Post-fakeroot scripts (+BR2_ROOTFS_POST_FAKEROOT_SCRIPT+)::
+
When aggregating the final images, some parts of the process requires
root rights: creating device nodes in `/dev`, setting permissions or
ownership to files and directories... To avoid requiring actual root
rights, Buildroot uses +fakeroot+ to simulate root rights. This is not
a complete substitute for actually being root, but is enough for what
Buildroot needs.
+
Post-fakeroot scripts are shell scripts that are called at the 'end' of
the fakeroot phase, 'right before' the filesystem image generator is
called. As such, they are called in the fakeroot context.
+
Post-fakeroot scripts can be useful in case you need to tweak the
filesystem to do modifications that are usually only available to the
root user.
+
.Note:
It is recommended to use the existing mechanisms to set file permissions
or create entries in `/dev` (see xref:customize-device-permission[]) or
to create users (see xref:customize-users[])
+
.Note:
The difference between post-build scripts (above) and fakeroot scripts,
is that post-build scripts are not called in the fakeroot context.
+
.Note;
Using `fakeroot` is not an absolute substitute for actually being root.
`fakeroot` only ever fakes the file access rights and types (regular,
block-or-char device...) and uid/gid; these are emulated in-memory.
include::customize-device-permission-tables.txt[]
|