Attempting to build qemux86

Im encountering an error when attempting to build vyos with qemux86 machine type.
`bitbake vyos-image
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
Loading cache: 100% |################################################################################################################################################################################################################################| Time: 0:00:00
Loaded 3289 entries from dependency cache.
WARNING: No recipes available for:
/home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-mtk_%.bbappend
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.39.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "centos-7"
TARGET_SYS = "i586-oe-linux"
MACHINE = "qemux86"
DISTRO = "vyos"
DISTRO_VERSION = "0.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "master:ce192a5cdc1c8a93f83e39194f4c74b5d2da2e36"
meta-oe
meta-python
meta-networking
meta-filesystems
meta-webserver
meta-perl = "master:b56fc26fefff498b10236ea6486a5d5624f726cc"
meta-vyos = "master:c0e61a84d2251b7f48535acd011b4fba62617b2d"
meta-swupdate = "master:83ea4936bee71f6b6132a76e17ef69974ff30d6a"
meta-sysrepo = "master:f966edff8a88cf0834b55cb151d2cb3443ba53a6"
meta-virtualization = "master:1bcc2431a50df3266e7c5b11c7a6de1422fa07b2"
meta-intel = "master:7c469177e833a80443b948af63e40176c7dc6bee"`

bblayer:
`# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

changes incompatibly

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= "
/home/testusr/poky/meta
/home/testusr/poky/meta-poky
/home/testusr/poky/meta-yocto-bsp
/home/testusr/poky/meta-openembedded/meta-oe
/home/testusr/poky/meta-openembedded/meta-python
/home/testusr/poky/meta-openembedded/meta-networking
/home/testusr/poky/meta-openembedded/meta-filesystems
/home/testusr/poky/meta-openembedded/meta-webserver
/home/testusr/poky/meta-openembedded/meta-perl
/home/testusr/poky/meta-vyos
/home/testusr/poky/meta-swupdate
/home/testusr/poky/meta-sysrepo
/home/testusr/poky/meta-virtualization
/home/testusr/poky/meta-intel
"
`

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.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 ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"

This sets the default machine to be qemux86 if no other machine is selected:

#MACHINE ??= "qemux86"
#MACHINE ??= "qemux86"
#MACHINE ??= "genericx86-64"
#MACHINE ??= "genericx86"
MACHINE ??= "qemux86"

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"
GOVERSION = "1.10%"

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"
IMAGE_FSTYPES += "wic.qcow2"

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"
DISTRO ?= "vyos"

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_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 and x86_64

#SDKMACHINE ?= "i686"
DISTRO_FEATURES_append = " virtualization"
LAYERSERIES_COMPAT_sysrepo = "sumo"

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)

"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/image.bbclass and meta/classes/core-image.bbclass for more details.

We default to enabling the debugging tweaks.

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
CORE_IMAGE_EXTRA_INSTALL = "
kernel-modules
kubernetes
docker
lrzsz
setserial
hostapd
strongswan
quagga
opkg
nbench-byte
alsa-utils
i2c-tools
devmem2
dosfstools
libdrm-tests
netkit-ftp
iptables
iproute2
bridge-utils
socat
wget
curl
vlan
dhcp-server
dhcp-client
hostapd
ntp
libstdc++
nginx
ppp
proftpd
boost
openssl
openssh
fcgi
mc
ethtool
minicom
procps
sysrepo
netopeer2-server
netopeer2-cli
netopeer2-keystored
netdata
tcpdump
file"
KERNEL_MODULE_AUTOLOAD += "ip_gre"
EXTRA_USERS_PARAMS = "usermod -P thincpe root;"
PACKAGE_EXCLUDE += " procps packagegroup-core-ssh-dropbear go "

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

- 'image-mklibs' to reduce shared library files size for an image

- 'image-prelink' in order to prelink the filesystem image

NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink

NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended

USER_CLASSES ?= "buildstats image-mklibs image-prelink"

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. To

enable this uncomment this line. See classes/testimage(-auto).bbclass for

further details.

#TEST_IMAGE = "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 that 100MB or 1K inodes, perform a hard abort

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 necesary 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
ABORT,${TMPDIR},100M,1K
ABORT,${DL_DIR},100M,1K
ABORT,${SSTATE_DIR},100M,1K
ABORT,/tmp,10M,1K"

Shared-state files from other locations

As mentioned above, shared state files are prebuilt cache data objects which can

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 http 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://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n
#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 the following line. This will mean the build uses

the network to check for artefacts at the start of builds, which does slow it down

equally, it will also 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.

#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"

Qemu configuration

By default qemu will build with a builtin VNC server where graphical output can be

seen. The two lines below enable the SDL backend too. 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.

PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl2-native"

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 = "1"`

Error encountered:
WARNING: linux-vyos-4.14.26-r0 do_fetch: Failed to fetch URL file://defconfig, attempting MIRRORS if available ERROR: linux-vyos-4.14.26-r0 do_fetch: Fetcher failure: Unable to find file file://defconfig anywhere. The paths that were searched were: /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/vyos /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/vyos /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/vyos /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/vyos /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/qemux86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/qemux86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/qemux86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/qemux86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/qemuall /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/qemuall /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/qemuall /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/qemuall /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/x86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/x86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/x86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/x86 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/i586 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/i586 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/i586 /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/i586 /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/ /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos-4.14.26/ /home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos/ /home/testusr/poky/meta-vyos/recipes-kernel/linux/files/ /home/testusr/poky/vyos-build/downloads ERROR: linux-vyos-4.14.26-r0 do_fetch: Fetcher failure for URL: 'file://defconfig'. Unable to fetch URL from any source. ERROR: linux-vyos-4.14.26-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /home/testusr/poky/vyos-build/tmp-glibc/work/qemux86-oe-linux/linux-vyos/4.14.26-r0/temp/log.do_fetch.23478 ERROR: Task (/home/testusr/poky/meta-vyos/recipes-kernel/linux/linux-vyos_4.14.26.bb:do_fetch) failed with exit code '1'

wtolkien / meta-vyos Goto Github PK

meta-vyos's Introduction

meta-vyos

meta-vyos's People

Contributors

Stargazers

Forkers

meta-vyos's Issues