2012-11-11 04:14:50 +01:00
|
|
|
// -*- mode:doc; -*-
|
2013-02-13 13:59:02 +01:00
|
|
|
// vim: set syntax=asciidoc:
|
2012-11-11 04:14:50 +01:00
|
|
|
|
|
|
|
Frequently Asked Questions & Troubleshooting
|
|
|
|
============================================
|
|
|
|
|
|
|
|
[[faq-boot-hang-after-starting]]
|
|
|
|
The boot hangs after 'Starting network...'
|
|
|
|
------------------------------------------
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
If the boot process seems to hang after the following messages
|
2012-11-11 04:14:50 +01:00
|
|
|
(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
|
2012-11-16 05:54:19 +01:00
|
|
|
serial console, you have to go into the Buildroot configuration, +System
|
2012-11-11 04:14:50 +01:00
|
|
|
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-no-compiler-on-target]]
|
2012-11-16 05:54:19 +01:00
|
|
|
Why is there no compiler on the target?
|
2012-11-11 04:14:50 +01:00
|
|
|
---------------------------------------
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
It has been decided that support for the _native compiler on the
|
|
|
|
target_ would be stopped from the Buildroot-2012.11 release because:
|
2012-11-11 04:14:50 +01:00
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
* this feature was neither maintained nor tested, and often broken;
|
2012-11-11 04:14:50 +01:00
|
|
|
* this feature was only available for Buildroot toolchains;
|
|
|
|
* Buildroot mostly targets _small_ or _very small_ target hardware
|
2012-11-16 05:54:19 +01:00
|
|
|
with limited resource onboard (CPU, ram, mass-storage), for which
|
2012-11-11 04:14:50 +01:00
|
|
|
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
|
2012-11-16 05:54:19 +01:00
|
|
|
distribution_ and you should opt for something like:
|
2012-11-11 04:14:50 +01:00
|
|
|
|
|
|
|
* 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]]
|
2012-11-16 05:54:19 +01:00
|
|
|
Why are there no development files on the target?
|
|
|
|
-------------------------------------------------
|
2012-11-11 04:14:50 +01:00
|
|
|
|
|
|
|
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]]
|
2012-11-16 05:54:19 +01:00
|
|
|
Why is there no documentation on the target?
|
2012-11-11 04:14:50 +01:00
|
|
|
--------------------------------------------
|
|
|
|
|
|
|
|
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-why-not-visible-package]]
|
2012-11-16 05:54:19 +01:00
|
|
|
Why are some packages not visible in the Buildroot config menu?
|
2012-11-11 04:14:50 +01:00
|
|
|
---------------------------------------------------------------
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
If a package exists in the Buildroot tree and does not appear in the
|
2012-11-11 04:14:50 +01:00
|
|
|
config menu, this most likely means that some of the package's
|
|
|
|
dependencies are not met.
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
To know more about the dependencies of a package, search for the
|
|
|
|
package symbol in the config menu (see xref:make-tips[]).
|
2012-11-11 04:14:50 +01:00
|
|
|
|
|
|
|
Then, you may have to recursively enable several options (which
|
2012-11-16 05:54:19 +01:00
|
|
|
correspond to the unmet dependencies) to finally be able to select
|
2012-11-11 04:14:50 +01:00
|
|
|
the package.
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
If the package is not visible due to some unmet toolchain options,
|
2012-11-11 04:14:50 +01:00
|
|
|
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?
|
|
|
|
-------------------------------------------------------
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
There are plenty of reasons to *not* use the target directory a chroot
|
2012-11-11 04:14:50 +01:00
|
|
|
one, among these:
|
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
* file ownerships, modes and permissions are not correctly set in the
|
2012-11-11 04:14:50 +01:00
|
|
|
target directory;
|
2012-11-16 05:54:19 +01:00
|
|
|
* device nodes are not created in the target directory.
|
2012-11-11 04:14:50 +01:00
|
|
|
|
2012-11-16 05:54:19 +01:00
|
|
|
For these reasons, commands run through chroot, using the target
|
2012-11-27 12:59:17 +01:00
|
|
|
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.
|