I currently have a buildroot configuration that outputs a U-Boot-wrapped root filesystem. Part of that process overlays files from a outside directory, which contains things like network interfaces, profile.d scripts, and some custom executables.
My question is this: what is the best way to recreate the root filesystem image, without rebuilding all the extra packages? Just deleting the output/images and output/target directories, followed by a "make all" doesn't seem to work. For the most common usage, I don't need to rebuild the toolchain, or any other packages. I just need the root filesystem recreated, with the overlay performed. However, there doesn't seem to be a good make target to do a clean on the output only, or a build of the target filesystem/images.
Thanks,
-D
Every time you invoke "make", the root filesystem image is completely re-created from the contents of output/target/, the post-build scripts are executed and the rootfs overlays are copied.
So if you make a change to a rootfs overlay, a change to a post-build script, or you add/remove stuff from output/target/, simply running "make" is sufficient.
However, if your aim is to remove output/target/ completely with the hope that it will reinstall all packages, then indeed this doesn't work, and we have good reasons for not supporting this, because there are many situations where this can give an incorrect result.
Related
Is there anyway I can just call into a define such as LIBFOO_DIRCLEAN, and just do what was implemented in the define?
Inside HOST_LIBFOO_INSTALL_CMDS, I copy files to the target directory, and would like the 'make package-dirclean' to delete what was copied into the target directory. 'make clean', would obviously do this(any many more), but that is much more than I want to do.
I see the following buildroot variables. LIBFOO_EXTRACT_CMDS, LIBFOO_CONFIGURE_CMDS, LIBFOO_BUILD_CMDS, HOST_LIBFOO_INSTALL_CMDS, LIBFOO_INSTALL_TARGET_CMDS, etc.
make foo-dirclean is a simple tool that just deletes the package build directory. In most cases, when the list of files installed by a package does not change over time (only files content changes) you can simply rebuild the package and the target directory will be rebuilt correctly.
If you want you can implement your own foo-myclean step that implements your own logic. However you must understand deleting files in the target directory is not supported by Buildroot and thus you are on your own.
I'm using buildroot 2018.05 and I'm noticing that if I remove some files in my overlay that the files are still being copied into the rootfs. I thought that any changes made in the overlay would automatically propagate when running make again without requiring me to do make clean and then make again?
I want to avoid having to re-download all packages and at least avoid re-compiling the toolchain each time I make changes to the overlay.
Buildroot cannot "know" when files have been removed from the overlay; it just copies the files from the overlay into the target rootfs.
Although Buildroot does do some tracking of where each file comes from, this information is not definitive so it can't be used to remove files again. In particular, files created or overwritten by the rootfs overlay or by a post-build script are (currently) not tracked.
It is true that the information in the (current) manual is misleading: "when changes to the root filesystem overlay, a post-build script or a post-image script are made, there is no need for a full rebuild". This is a bug in the manual and should be fixed. Feel free to submit a patch.
I have a software that has multiple GUIs. To organize things better (or at least that was my thought), I have created several folders within the root directory as it can be seen in this image.
Within the folders i have both files with different formats and also some Matlab scripts.
When creating the Matlab executable using the Application compiler, and after selecting the main file, Matlab does not directly detected that these same folders are important for the code to run. Therefore I decided to add the folders manually.
Once the setup is created and installed, by running the application within the Matlab environment, I was able to debug one possible issue why the software is not running.
As you can see in the first image, the "play.png" is within the Images folder.
My question is pretty straight forward: how to force the Matlab Compiler to learn that all these folders are to be included in the setup? Not only to be included but their paths'
Two things could be going on:
You are not including the files in the package.
Make sure that you include them using the -a option of mcc:
mcc -m hello.m -a ./testdir/*
You can also use the GUI, of course, see here.
You are looking for the included files in the wrong place. Use ctfroot as the root of all paths in your code:
img_file_name = fullfile(ctfroot,'Images','brain.jpg'));
Check the unpacked CTF file (it is automatically unpacked when executed) to see the directory structure in it. ctfroot points to the root of the unpacked CTF file.
PS: This blog post might give you some more pointers.
In my yocto source deploy/images/beaglebone dir is nearly 100GB so i want to free that memory
Please help me how can I delete that deploy dir either manually or via command line
I want to clean all images(*.tar.gz,*.sdcard, *.ubifs) of previous compilation in yocto deploy/images/beaglebone/
Maybe when you are with 100GB in the deploy directory, things have gone too far already.
Check your IMAGE_FSTYPES variable. My experience says it is safe to delete all images of these files that are not symlinks, or symlinks targets. Avoid the last one generated to avoid breaking the last build link, and any related with bootloaders and configuration files, as they could be rarely regenerated.
If you are keeping more than one build with the same set of layers, then you can use a common download folder for builds.
DL_DIR ?= "common_dir_across_all_builds/downloads/"
And afterwards:
To keep your /deploy clean:
RM_OLD_IMAGE: Reclaims disk space by removing previously built versions of the same image from the images directory pointed to by the DEPLOY_DIR variable.Set this variable to "1" in your local.conf file to remove these images:
RM_OLD_IMAGE = "1"
IMAGE_FSTYPES Remove the image types that you do not plan to use, you can always enable a particular one when you need it:
IMAGE_FSTYPES_remove = "tar.bz2"
IMAGE_FSTYPES_remove = "rpi-sdimg"
IMAGE_FSTYPES_remove = "ext3"
For /tmp/work, do not need all the workfiles of all recipes. You can specify which ones you are interested in your development.
RM_WORK_EXCLUDE:
With rm_work enabled, this variable specifies a list of recipes whose work directories should not be removed. See the "rm_work.bbclass" section for more details.
INHERIT += "rm_work"
RM_WORK_EXCLUDE += "home-assistant widde"
try this from your build root rm -fr deploy/images. Here is a good discussion on the topic
I just removed the files manually like below
1. goto build/deploy/images/beaglebone
2. $ ll : you will find the softlinks of rootfs with time like
......*20170811091521.rootfs.tar.gz
......*-20170811091521.rootfs.sdcard etc
3. Dont delete recently compiled files. except these this you can remove all *.tar.gz, *.sdcard,*.ext4 manually like below,
4. rm beaglebone-20170811091521.rootfs.tar.gz
rm beaglebone-20170811091521.rootfs.sdcard
rm beaglebone-20170811091521.rootfs.ext4 etc.
I'm new to yocto. I'm trying to learn how the packages are added, how to create new layers and so on... just poking around. Started by cloning poky and playing around.
To my understanding, the bblayers.conf file is critical to the project configuration and what you end up building (what layers and packages go into your final image).
This might be the wrong assumption, but I also have a feeling that the build/ folder is where things you build (bitbake) stay. Images, lots of things needed to build them, a big cache of stuff... You can delete it and rebuild it if you somehow broke it. Or you can just copy everything without the build/ folder and continue working on a different computer.
Apparently it's not quite the case. The build/conf/ folder has the important .conf files like the bblayers.conf.
Can someone explain why is this the case? Is there an elegant way to separate the project config and the build folder?
There are a couple layers to the Yocto Project, mainly:
-BSPDIR: TOPDIR (build),sources,setup-environment
-BSPDIR/setup-environment: initial all the variable to for bitbake;
-BSPDIR/sources: meta-data/
-TOPDIR: conf/ sstate-cache/ cache/ tmp/ downloads/
-TOPDIR/downloads: recipe fetched packages;
-TOPDIR/conf/ : stored all the configuration. Mainly bblayers.conf, local.conf, sanity_info;
-TOPDIR/conf/bblayers.conf: stored all the path to meta-data that will be loaded;
-TOPDIR/conf/local.conf: configuration to build
-TOPDIR/conf/sanity_info: path double check to make sure that all the path used in the last compile match the current compile;
-TOPDIR/tmp/: Where all the compiling and building work happen
In BSPDIR/sources/poky/meta/conf/bitbake.conf
sources/poky/meta/conf/bitbake.conf:TMPDIR ?= "${TOPDIR}/tmp"
sources/poky/meta/conf/bitbake.conf:PERSISTENT_DIR = "${TOPDIR}/cache"
sources/poky/meta/conf/bitbake.conf:DL_DIR ?= "${TOPDIR}/downloads"
sources/poky/meta/conf/bitbake.conf:SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
TOPDIR is where you initialize when run setup-environment or oe-init-build-env; All the other bitbake configuration environment variable can be changed based on your need in conf/local.conf;
e.g. modify conf/local.conf to change the downloads directory from TOPDIR/downloads;
DL_DIR ?= "/home/downloads/"
To create new layer, please watch this video: https://www.youtube.com/watch?v=3HsaoVqX7dg
You might have followed the Yocto Project Quick Start Guide.
The earliest step in yocto after installing (cloning git repositories and installing packages) is to create your OE (OpenEmbedded) environment, which is done via:
source oe-init-build-env
This automatically creates and leads you to the build folder.
Matter that you can give any directory of your system as parameter for this call (Reference Manual - Build Overview):
source oe-init-build-env [build_dir]
⤑ This is also the step, where your 'project config' is separated from the actual build folder.
⤑ As you assumed, in practice you would at most copy the layers and not the build folder. Even better is to leave sources from others in their git repositories and only copy and maintain your own layers.
it is true an issue in the modern Yocto build system.
file bblayers.conf has to be synthesized based on MACHINE and DISTRO information using all provided (usually with the help of repo manifest file) layers by: collecting data from each available layer file layer.conf as well as conf/machine, conf/distro, images.
Instead bblayers.conf is usually copied over from the base layer conf/bblayers.conf location with the help of setup-environment script.
this approach provides no "one click" buildable environment but require maintainer/developer to look into readme to identify what layers are missing to be added to the build/conf/bblayers.conf.