From: Vivek Ojha <vivekojha13@gmail.com>
To: yocto@lists.yoctoproject.org
Subject: menuconfig fail for virtual/kernel while building image for meta-intel(intel-corei7-64)
Date: Thu, 29 Feb 2024 17:07:37 +0530 [thread overview]
Message-ID: <CAPNEe0jspOa2UmUO9pJRzo+mqWJfiQkGF3f6pvqFB5E7Mc+Tgw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 14629 bytes --]
Hi
While using " bitbake -c menuconfig virtual/kernel", the menuconfig
interface closes instantly.
While using "bitbake -c menuconfig busybox", the menuconfig opens perfectly
and I can make changes into the busybox config.
Please help me to figure out the issue of not opening the menuconfig
interface for kernel configuration.
Thanks in advance,
Kind regards
Vivek Ojha
BBLAYERS.conf:
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
/home/ti/vivek/source/poky/meta \
/home/ti/vivek/source/poky/meta-poky \
/home/ti/vivek/source/poky/meta-yocto-bsp \
/home/ti/vivek/source/meta-intel \
/home/ti/vivek/source/meta-openembedded/meta-oe \
/home/ti/vivek/source/meta-openembedded/meta-networking \
/home/ti/vivek/source/meta-openembedded/meta-filesystems \
"
LOCAL.conf:
#
# 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. There's also site.conf.sample which contains examples of site
specific
# information such as proxy server addresses.
#
# 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"
#
# This sets the default machine to be qemux86-64 if no other machine is
selected:
#MACHINE ??= "qemux86-64"
MACHINE = "intel-corei7-64"
# These are some of the more commonly used values. Looking at the files in
the
# meta/conf/machine directory, or the conf/machine directory of any
additional layers
# you add in will show all the available machines.
#
# 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"
# OE-Core defaults to ipkg, whilst Poky defaults to rpm:
# PACKAGE_CLASSES ?= "package_rpm"
#
# 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
# variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "src-pkgs" - add -src packages for all installed packages
# (adds source code for debugging)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the
image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "eclipse-debug" - add Eclipse remote debugging support
# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord
etc.)
# "debug-tweaks" - make an image suitable for development
# e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes-recipe/image.bbclass and
# meta/classes-recipe/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
#
# Additional image features
#
# The following is a list of additional classes to use when building images
which
# enable extra features. Some available options which can be included in
this variable
# are:
# - 'buildstats' collect build statistics
USER_CLASSES ?= "buildstats"
#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an
emulator)
# after any root filesystems are created and run tests against those
images. It can also
# run tests against any SDK that are built. To enable this uncomment these
lines.
# See meta/classes-recipe/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO:qemuall = "1"
#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do
this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one
parallel
# process may require the user's attention. The default is iterate over the
available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches
which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x
only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail
instead):
PATCHRESOLVE = "noop"
#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of
space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR),
gracefully
# shutdown the build. If there is less than 100MB or 1K inodes, perform a
hard halt
# of the build. The reason for this is that running completely out of space
can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necessary to monitor /tmp, if there is no space left the build will
fail
# with very exotic errors.
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"
#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects
which can be
# used to accelerate build time. This variable can be used to configure the
system
# to search other mirror locations for these objects before it builds the
data itself.
#
# This can be a filesystem directory, or a remote url such as https or ftp.
These
# would contain the sstate-cache results from previous builds (possibly
from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points
to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to
add PATH
# at the end as shown in the examples below. This will be substituted with
the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
#file://.* file:///some/local/dir/sstate/PATH"
#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you
can enable
# use of these by uncommenting some of the following lines. This will mean
the build uses
# the network to check for artefacts at the start of builds, which does
slow it down
# initially but it will then speed up the builds by not having to build
things if they are
# present in the cache. It assumes you can download something faster than
you can build it
# which will depend on your network.
# Note: For this to work you also need hash-equivalence passthrough to the
matching server
# There is a choice between our sstate server directly and a faster content
delivery network
# (CDN) kindly provided by JSDelivr, uncomment one of the SSTATE_MIRRORS
lines, not both.
# Using the CDN rather than the yoctoproject.org address is
suggested/preferred.
#
#BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
#SSTATE_MIRRORS ?= "file://.*
http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
#
###SSTATE_MIRRORS ?= "file://.*
http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
#
# Qemu configuration
#
# By default native qemu will build with a builtin VNC server where
graphical output can be
# seen. The line below enables the SDL UI frontend too.
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
# By default libsdl2-native will be built, if you want to use your host's
libSDL instead of
# the minimal libsdl built by libsdl2-native then uncomment the
ASSUME_PROVIDED line below.
#ASSUME_PROVIDED += "libsdl2-native"
# You can also enable the Gtk UI frontend, which takes somewhat longer to
build, but adds
# a handy set of menus for controlling the emulator.
#PACKAGECONFIG:append:pn-qemu-system-native = " gtk+"
#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server
and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash
doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"
#
# Memory Resident Bitbake
#
# Bitbake's server component can stay in memory after the UI for the
current command
# has completed. This means subsequent commands can run faster since there
is no need
# for bitbake to reload cache files and so on. Number is in seconds, after
which the
# server will shut down.
#
#BB_SERVER_TIMEOUT = "60"
# CONF_VERSION is increased each time build/conf/ changes incompatibly and
is used to
# track the version of this file when it was generated. This can safely be
ignored if
# this doesn't mean anything to you.
CONF_VERSION = "2"
LICENSE_FLAGS_ACCEPTED = "commercial"
#PREFERRED_PROVIDER_virtual/kernel ?= "linux-intel"
#PREFERRED_VERSION_linux-intel = "5.15.137"
IMAGE_INSTALL:append = " pciutils"
IMAGE_INSTALL:append = " i2c-tools"
IMAGE_INSTALL:append = " usbutils"
IMAGE_INSTALL:append = " openssh"
IMAGE_INSTALL:append = " sudo"
MACHINE_FEATURES = " pci"
#Package for filesystem identification
IMAGE_INSTALL:append = " util-linux"
#Package For mountingext2, ext3, or ext4 filesystems
IMAGE_INSTALL:append = " e2fsprogs"
#Package For mounting NTFS filesystems
IMAGE_INSTALL:append = " ntfs-3g"
#Package For mounting FAT filesystems
IMAGE_INSTALL:append = " dosfstools"
# provides detailed information about the network interface card (Ethernet
Card)
IMAGE_INSTALL:append = " ethtool"
#OE_TERMINAL = "screen"
#IMAGE_FSTYPES += " hddimg"
#IMAGE_FSTYPES += " wic.xz"
#IMAGE_ROOTFS_EXTRA_SPACE = "0"
#IMAGE_NAME_SUFFIX = ""
#IMAGE_INSTALL_append =+ "gstreamer1.0-plugins-good
gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-libav
gstreamer1.0-vaapi"
[-- Attachment #2: Type: text/html, Size: 17174 bytes --]
reply other threads:[~2024-02-29 11:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPNEe0jspOa2UmUO9pJRzo+mqWJfiQkGF3f6pvqFB5E7Mc+Tgw@mail.gmail.com \
--to=vivekojha13@gmail.com \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).