After commit e8b1c65394, we started seeing
errors like the following during boot on genericx86 machines:
uvesafb: failed to execute /sbin/v86d
uvesafb: probe of uvesafb.0 failed with error -22
uvesafb: vbe_init() failed with -22
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
These were caused because the uvesa module was being loaded during boot,
when it is only meant to be loaded on qemu according to:
6af89812e8
Since genericx86-common.inc includes qemuboot-x86, the module also tries
to be loaded on genericx86 machines, this patch removes the instruction from
qemuboot-x86 and adds it in specific to both qemux86 machines confs so
it is correctly loaded only on those.
[YOCTO #11879]
(From OE-Core rev: 261f9c382121c73b72556a151fdd4c7938b32a92)
(From OE-Core rev: 554903483acb4af402feaba013366388db89e36b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is an issue for requesting dynamic IP with ifup/ifdown command
when using dhclient.
Steps to reproduce:
1. Build a full-cmdline image and install dhcp-client as the default DHCP client.
2. Configure a static IP for eth0 in /etc/networking/interfaces and reboot.
$ ifconfig eth0
eth0 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
$ ifdown eth0
3. Modify /etc/networking/interfaces to configure a dynamic IP for eth0
$ ifup eth0
$ ifconfig eth0
eth0 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
You could see the eth0 still has a static IP. But actually it also has a
dynamic IP:
$ ip addr show eth0
eth0:
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
inet 128.224.162.173/23 brd 128.224.163.255 scope global eth0
The root cause is the ifdown invokes "ifconfig" to down the eth0 but
doesn't remove its IP. The dhclient would invoke "ip" to configure the
interface. It can not remove an IP from down interface with "ip addr
flush" and "ip addr add" command can set multiple IPs on one interface.
To fix this issue, we should use the "ip" command to implement
ifup/ifdown, rather than using the older "ifconfig". It will flush the
IP before down the interface.
(From OE-Core rev: 4304ed013a015bfb6f054017cb273578b874b4c2)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Device Tree is commonly used but it is still kept as a .inc file
instead of a proper class. Instead now we move the Device Tree code to
a kernel-devicetree class and automatically enable it when the
KERNEL_DEVICETREE variable is set.
To avoid breakage in existing layers, we kept a linux-dtb.inc file
which raises a warning telling the user about the change so in next
release this can be removed.
(From OE-Core rev: 03a00be7f2062aefef0e51ef20a4c9737f6685e7)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need QEMU PID in order to access "/proc/<qemupid>/cmdline"
Having a valid QEMU PID does not mean we can access the proc entry
immediately, we need to wait for the /proc/<qemupid> to appear
before we can access it.
(From OE-Core rev: d2d069fa9910d1c7a94c898355a63fca03ec5ad8)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in scriptutils which implements the logic for running the
editor used by devtool edit-recipe looks at the VISUAL environment
variable before EDITOR, and thus if VISUAL is set in the environment it
will override the EDITOR value we are setting here, the editor (usually
vim) launches and there's nothing to stop it running forever short of
manually killing it. Set VISUAL instead to fix this.
Apparently VISUAL is in fact the variable we should really be preferring
here - I don't think I knew that but somehow I got it right in the code,
just not in the test. Here are the details for the curious:
https://unix.stackexchange.com/questions/4859/visual-vs-editor-whats-the-difference
Fixes [YOCTO #12074].
(From OE-Core rev: 6a7c50def569b5e86aa17bd9b287e8c63781dcb0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updated the kernel development flow diagram to have an arrow from
the repositories to the box that says you need to clone the
kernel repository. Also, provided some wording changes in the
end of the chapter.
(From yocto-docs rev: c77cff4f7b0795d5429dc47c2ad63aec6d19d513)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added the linux-yocto-4.12 kernel repository and the linux-yocto-cache
repository to the list of Yocto Linux Kernel repositories in the
Source Repositories.
(From yocto-docs rev: 88fedda0fa4a4dfc468f0dc404fa9f04390cbed7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switching to kernel version 4.12. Pulled some old commented
stuff out.
(From yocto-docs rev: c0a5c886256d3477ddaf670df4939bec1c73152e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added in a sentence to point to the kernel-dev manual should
the user be interested in kernel development.
(From yocto-docs rev: cc47606af5b7eb2fdc669aa2c0c4dfbd930b8247)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I moved the flow diagram up higher and completely removed
the procedures to get the build host ready for kernel
development. Those are now in the common tasks chapter.
Lots of rewriting
Signen-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Had to account for devtool and traditional kernel methods
now.
(From yocto-docs rev: 74580d9a61fa012406059ba2a3348d38fdc24d4c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11762]
Added a link from variable to new virtual providers
section.
(From yocto-docs rev: d87726cf4962ca093c63d23d9e04f41d448c9594)
Signed-off-by: Kristi Rifenbark <kristi.rifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12031]
Applied minor wording changes based on review feedback.
(Bitbake rev: f0930f3216a8358759d561d244fa280932e8bf05)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12029]
There were four links to an old blog post that was leveraged
for the hello world example. The post has evidently been
removed and the links no longer resolved. I have taken them out.
(Bitbake rev: db298262189c94be700abfdb8c2ad7827b53afca)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12031]
Moved an inappropriate example from the bottom of the INHERIT
Configuration Directive section up into the inherit directive
section.
Updated the example at the end of the INHERIT Configuration
Directive section to apply to INHERIT.
(Bitbake rev: f169ac5da18d55a40d0554668e1a0ace70f94768)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12032]
I applied some re-writing to help clarify the relationships between
the inherit, include, and require directives.
(Bitbake rev: fded970a0709d928f70224d8b61534e9353ee6dd)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printing the last 10 lines of bitbake-cookerdaemon.log when the server
fails to start can sometimes result in printing the output from a
previous run, which could lead the user completely down the wrong path
in terms of the cause of the failure. Use a known start text containing
the time which we can then look for when scanning through the log, and
then grab the last 10 lines of that part instead.
Fixes [YOCTO #11903].
(Bitbake rev: 567f2cf1bc455b4f3cfb1cbd7f25145360b05a62)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The whitelist shouldn't have to be populated in order for the
enforcement to work properly - check if the list is not None in order to
determine whether the functionality is enabled or not since that is how
the function that sets up the list behaves.
(Bitbake rev: 7b1e79c352ca6eef1693d8abfacf7505544f1caa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issues in start are not being correctly detected by the current readypipe
code. Change it to use specific "ready" or "fail" messages to correctly
determine the correct failure mode and avoid bitbake seeming to hang
(it does currently timeout eventually).
[YOCTO #12062]
(Bitbake rev: 60d4791e3dd05729d2a2adf6f3b203c80d466a73)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable cross-canadian builds of the Go toolchain. This
requires an additional patch to the Go source to allow us
to use the native GOTOOLDIR during the bootstrap phase.
(From OE-Core rev: 9daa02f63a0d53ab90a515f2bd3e783187c9415b)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of hard-coding GOARM to ${TARGET_GOARM} in
the wrapper script, take it from an existing
environment setting if present. This allows the
same cross-compiler to be used for different ARM
targets.
(From OE-Core rev: 1d319f102cd1f37ce5629c73948efae01478f866)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
to make it clearer that it is only used for building
the toolchain for the target.
(From OE-Core rev: 780aa334f8614c80ce5b9cb77b0cea2fcd482614)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use conditional assignment for the CGO_xxx
variables, so they can be overridden more easily
* remove the TOOLCHAIN_OPTIONS and TARGET_CC_ARCH
references, since those are already present in
CC and CXX
* remove the TARGET_ prefix so the values are
appropriate for native, nativesdk, etc. builds
* move the GOROOT export away from the CGO settings
and closer to its definition
(From OE-Core rev: 088528021d6979a8e2d6bc33d63a166e300cfde4)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The src content has been moved to -dev package, so does the test
routines. Fix the runtime dependency accordingly.
(From OE-Core rev: 53bbd2222027b7bbca8df066a8a9a58355ae0f91)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GOROOT_FINAL is used by the Go linker for rewriting
source paths when the build GOROOT is not the same
as the runtime GOROOT, but the other _FINAL variables
aren't really needed.
(From OE-Core rev: 31aa0d8a62be95d093d3c7581efa41f74b9131ad)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reorganize the Go toolchain build to split out
the Go standard runtime libraries into a separate
recipe. This simplifies the extension to crosssdk
and cross-canadian builds.
* Adds a patch to the go build tool to prevent it
from trying to rebuild anything in GOROOT, which
is now resident in the target sysroot.
* 'go' bb and inc files are now for building the
compiler for the target only.
* 'go-cross' bb and inc files are now just for
the cross-compiler.
* Adds virtual/<prefix> PROVIDES for the compiler
and runtime
* Removes testdata directories from the sysroot
during staging, as they are unnecessary and
can cause strip errors (some of the test files
are ELF files).
* Re-enables pacakage QA checks, adding selective
INSANE_SKIP settings where needed.
(From OE-Core rev: d2a7af7cd834e218c39d43ee3fa0c14d4f748727)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The go1.4 toolchain is only required for bootstrapping
go-native, and should not be used for anything else,
so build it as part of the go-native build. This way,
we don't have to carry around its built artifacts in
the native sysroot.
The go-cross and target toolchains can then just depend
on go-native, using that for their 'bootstrap' toolchain.
Also removed some unnecessary package-related noexec
settings, since native recipes inherit nopackages.
(From OE-Core rev: 9dc9d457fb9a456bc18c7789b91f40e1f6a999fe)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
iproute2 has the ability to include a tipc tool. When enabled this requires
the libmnl package (formerly supplied by meta-openembedded). So both are
needed at the same time.
The change itself is needed because of the tipc-utils package (in
meta-openembedded) which RDEPENDS on iproute2-tipc. Without this package
the yocto-compat-layer script indicates there is no way for me to have
meta-openembedded pass the checker. This is because meta-openembedded is
not allowed to just enable 'tipc' on it's own. (A layer may not make distro
wide changes without a user saying to do it.) The checker script invokes
bitbake -S none world, which will fail on dependency resolution due to there
being no iproute2-tipc package. The tipc-utils package does not have a way
to check the PACKAGECONFIG of the iproute2 package so disable itself if the
dependency can not be met. So the default system behavior needs to be:
iproute2 w/ tipc enabled
tipc-utils RDEPENDS on iproute2-tipc
(From OE-Core rev: b40f42e69de47af4f627432e284038c645efbaec)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The high-level method tempfile.TemporaryDirectory give us no way to
ignore erros on removal thus use tempfile.mkdtemp instead. Ignoring possible issues
on removal is neccesary because it contains gpg sockets that are automatically removed
by the system once the process terminates, otherwise the following log is observed:
..
..
File "/usr/lib/python3.5/shutil.py", line 436, in _rmtree_safe_fd
os.unlink(name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 'S.gpg-agent.browser'
[YOCTO #11821]
(From OE-Core rev: 7e3a7cd2426feac757def81850dc44156cd0f33e)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use a tempdir to copy the .config file from the kernel instead of being
copied to build directory.
(From OE-Core rev: ccccf975c75055639c0ed5052ac0ad53ebbf53ca)
Signed-off-by: Jose Perez Carranza <jose.perez.carranza@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it's used by bzr fetcher:
meta/conf/bitbake.conf:FETCHCMD_bzr = "/usr/bin/env bzr"
and when it isn't available in PATH do_fetch tasks fail with:
/usr/bin/env: ‘bzr’: No such file or directory
* it was also added in:
https://patchwork.openembedded.org/patch/140107/
but this change wasn't merged (nor rejected AFAIS)
(From OE-Core rev: c7ba7e9e7a7ca2caf453106112dc5a3c855b21d3)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
