[yocto] Remove kernel image and modules from rootfs
Hi,
I am creating a rootfs/bootloader/kernel to run on a beaglebone black
usually and it works great.
So I have in conf/local.conf
MACHINE ?= "beaglebone-yocto"
and an own layer meta-insidem2m which defines some image settings in
recipes-core/images/insidem2m-s.bb among other recipes for packages and
package modification.
Now I wan't to create a rootfs without the kernel image and the kernel
modules to make it as small as possible to use it as a basis to run as a
docker image.
Now I wonder how to instruct bitbake to not put the kernel image (and
modules) into the rootfs.
I read this was done by
RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""
but this is now deprecated for kirkstone and should be done this way:
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
But rootfs always still is equipped with kernel and modules.
I tried all permutations of
#RDEPENDS_kernel-base = ""
#MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
#RDEPENDS_kernel-base = ""
#PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
# Don't include kernels in standard images
##RDEPENDS:kernel-base = ""
#RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
#MACHINE_EXTRA_RRECOMMENDS = ""
#RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""
in my conf/local.conf but no avail...
How is this done correctly?
Are there any variables to check I might have (being) set preventing me
to do this? Or is it necessary to split out a new MACHINE, i.e. can this
only be done in an own created machine which has to be split out?
I thought setting such at the bottom of conf/local.conf always "wins".
Kind Regards
Konstantin
--
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen
Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010
konstantin.kletsc...@inside-m2m.de
http://www.inside-m2m.de
Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58856): https://lists.yoctoproject.org/g/yocto/message/58856
Mute This Topic: https://lists.yoctoproject.org/mt/95815345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FireFox
On Wed, 2022-12-21 at 06:17 -0800, jovanbosi...@gmail.com wrote: > Thank you for your help! Is there any other option instead of core- > image-sato? Perhaps you could mention the issue with core-image-sato which means you can't use it? There are other options but asking us to randomly guess which ones you might be able to use without knowing your criteria isn't much fun! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58855): https://lists.yoctoproject.org/g/yocto/message/58855 Mute This Topic: https://lists.yoctoproject.org/mt/95802925/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FireFox
Thank you for your help! Is there any other option instead of core-image-sato? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58854): https://lists.yoctoproject.org/g/yocto/message/58854 Mute This Topic: https://lists.yoctoproject.org/mt/95802925/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FireFox
> 2. Image I am building is core-image-minimal-dev > 6. After I start my machine and enter firefox in command line this error > occurs: no DISPLAY environment variable specified core-image-minimal doesn’t come with a graphical interface (specifically, no X server), so an application which expects an X server won’t work (specifically, firefox). core-image-sato is a better starting point, as that includes an X server, desktop, panel, etc. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58853): https://lists.yoctoproject.org/g/yocto/message/58853 Mute This Topic: https://lists.yoctoproject.org/mt/95802925/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FireFox
On Wed, Dec 21, 2022 at 12:39 AM wrote: %< SNIP %< *6. After I start my machine and enter firefox in command line this error > occurs: no DISPLAY environment variable specified* > > The DISPLAY variable is the host that is running the X server that will display your Firefox window. Since you said you are running the image as a virtual machine in VirtualBox, then you probably mean to have an X server running on your host machine that can display the windows exported by your virtual machine. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58852): https://lists.yoctoproject.org/g/yocto/message/58852 Mute This Topic: https://lists.yoctoproject.org/mt/95802925/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] FireFox
Hi everyone,
I am trying to add firefox to my yocto project. I am now at this so I need a
few hints.
*1. I am using yocto kirkstone*
*2. Image I am building is core-image-minimal-dev*
*3. My local.conf file looks like this:*
#
# This file is your local configuration file and is where all local user
settings
# are placed. The comments in this file give some guide to the options a new
user
# to the system might want to change but pretty much any configuration option
can
# be set in this file. More adventurous users can look at
# local.conf.sample.extended which contains other examples of configuration
which
# can be placed in this file but new users likely won't need any of them
# initially.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax.
Enabling
# the option is a question of removing the # character and making any change to
the
# variable as required.
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a
selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86-64 if no other machine is
selected:
MACHINE ??= "qemux86-64"
#
# Where to place downloads
#
# During a first build the system will download many different source code
tarballs
# from various upstream projects. This can take a while, particularly if your
network
# connection is slow. These are all stored in DL_DIR. When wiping and
rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This
directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build
directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"
#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built
output.
# This is done using "shared state" files which can be thought of as cache
objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would
regenerate
# from these files if no changes were made to the configuration. If changes
were made
# to the configuration, only shared state files where the state was still valid
would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the
toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"
#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream
# source control systems. This is just mentioned here as an example, its not
# useful to most new users.
# DISTRO ?= "poky-bleeding"
#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package
backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
# - 'package_deb' for debian style deb files
# - 'package_ipk' for ipk files are used by opkg (a debian style embedded
package manager)
# - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to rpm:
PACKAGE_CLASSES ?= "package_deb"
#
# SDK target architecture
#
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you
are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686, x86_64, aarch64
#SDKMACHINE ?= "i686"
#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the
generated
# images. Some of these options are added to certain image types automatically.
The
# va
