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; -*-
Frequently Asked Questions & Troubleshooting
============================================
[[faq-boot-hang-after-starting]]
The boot hangs after 'Starting network...'
------------------------------------------
If the boot process seems to hang after the following messages
(messages not necessarily exactly similar, depending on the list of
packages selected):
------------------------
Freeing init memory: 3972K
Initializing random number generator... done.
Starting network...
Starting dropbear sshd: generating rsa key... generating dsa key... OK
------------------------
then it means that your system is running, but didn't start a shell on
the serial console. In order to have the system start a shell on your
serial console, you have to go into the Buildroot configuration, +System
configuration+, and modify +Port to run a getty (login prompt) on+ and
+Baudrate to use+ as appropriate. This will automatically tune the
+/etc/inittab+ file of the generated system so that a shell starts on
the correct serial port.
[[faq-module-init-tool-build-failure]]
module-init-tools fails to build with 'cannot find -lc'
-------------------------------------------------------
If the build of +module-init-tools+ for the host fails with:
------------------------
/usr/bin/ld: cannot find -lc
------------------------
then probably you are running a Fedora (or similar) distribution, and
you should install the +glibc-static+ package. This is because the
+module-init-tools+ build process wants to link statically against the
C library.
[[faq-no-compiler-on-target]]
Why is there no compiler on the target?
---------------------------------------
It has been decided that support for the _native compiler on the
target_ would be stopped from the Buildroot-2012.11 release because:
* this feature was neither maintained nor tested, and often broken;
* this feature was only available for Buildroot toolchains;
* Buildroot mostly targets _small_ or _very small_ target hardware
with limited resource onboard (CPU, ram, mass-storage), for which
compiling does not make much sense.
If you need a compiler on your target anyway, then Buildroot is not
suitable for your purpose. In such case, you need a _real
distribution_ and you should opt for something like:
* http://www.openembedded.org[openembedded]
* https://www.yoctoproject.org[yocto]
* http://www.emdebian.org[emdebian]
* https://fedoraproject.org/wiki/Architectures[Fedora]
* http://en.opensuse.org/Portal:ARM[openSUSE ARM]
* http://archlinuxarm.org[Arch Linux ARM]
* ...
[[faq-no-dev-files-on-target]]
Why are there no development files on the target?
-------------------------------------------------
Since there is no compiler available on the target (see
xref:faq-no-compiler-on-target[]), it does not make sense to waste
space with headers or static libraries.
Therefore, those files are always removed from the target since the
Buildroot-2012.11 release.
[[faq-no-doc-on-target]]
Why is there no documentation on the target?
--------------------------------------------
Because Buildroot mostly targets _small_ or _very small_ target
hardware with limited resource onboard (CPU, ram, mass-storage), it
does not make sense to waste space with the documentation data.
If you need documentation data on your target anyway, then Buildroot
is not suitable for your purpose, and you should look for a _real
distribution_ (see: xref:faq-no-compiler-on-target[]).
[[faq-depends-on-vs-select]]
+Config.in+: _depends on_ vs _select_
-------------------------------------
When adding a new package to Buildroot, you will most likely have to
deal with expressing the dependencies of this package.
In the +Config.in+ file, dependencies may be expressed following two
semantics.
See xref:depends-on-vs-select[choosing between _depends_ and _select_].
[[faq-why-not-visible-package]]
Why are some packages not visible in the Buildroot config menu?
---------------------------------------------------------------
If a package exists in the Buildroot tree and does not appear in the
config menu, this most likely means that some of the package's
dependencies are not met.
To know more about the dependencies of a package, search for the
package symbol in the config menu (see xref:make-tips[]).
Then, you may have to recursively enable several options (which
correspond to the unmet dependencies) to finally be able to select
the package.
If the package is not visible due to some unmet toolchain options,
then you should certainly run a full rebuild (see xref:make-tips[] for
more explanations).
[[faq-why-not-use-target-as-chroot]]
Why not use the target directory as a chroot directory?
-------------------------------------------------------
There are plenty of reasons to *not* use the target directory a chroot
one, among these:
* file ownerships, modes and permissions are not correctly set in the
target directory;
* device nodes are not created in the target directory.
For these reasons, commands run through chroot, using the target
directory as the new root, will most likely fail.
If you want to run the target filesystem inside a chroot, or as an NFS
root, then use the tarball image generated in +images/+ and extract it
as root.
|
