Yocto:ImageBuild:Stlinux

Der User seife hat diverse Recipies für das Yocto Buildsystem erstellt, die es ermöglichen ein Neutrino-MP für verschiedene Typen von Settopboxen zu erstellen. Momentan kann man USB Images und entsprechende Softwarepakete für die Receiver der 1. Generation (armv6 basierend) von Coolstream, für die SH4 basierten Boxen mit dem Prozessortypen STI7111 und STI7162, für die Tripledragon und den Raspberry (nicht Version 2) erstellen.

Dieser Artikel befasst sich mit dem Yocto System für die STLinux basierten Spark Boxen.

Vorbereitungen

Pakete installieren

Für Debian basierte Systeme (getestet mit Wheezy und Jessie in 32/64bit).

$ sudo apt-get update
$ sudo apt-get install libsdl1.2-dev chrpath git build-essential automake texinfo

Für OpenSuse (getestet mit OpenSuse 42.3/15.0 64bit)

$ sudo zypper install git make gcc-g++ diffstat texinfo chrpath libSDL-devel python3-curses zip glew-devel freeglut-devel libid3tag-devel libmad-devel libogg-devel libsigc++2-devel flac-devel 
libvorbis-devel yasm

Bei Bedarf kann man weitere benötigte Pakete auch mit Hilfe der Suse Downloadsuche direkt nachinstallieren:

https://software.opensuse.org/search

Des Weiteren benötigt man ein extra Verzeichnis im $HOME in dem man alle nötigen Verzeichnisse samt zusätzlicher Unterverzeichnisse anlegen kann. Im folgenden wird $HOME/yocto verwendet, das kann natürlich jeder seinen Gepflogenheiten anpassen. Achtung, ein späteres Verschieben ist nicht einfach möglich da innerhalb der erzeugten Toolchain mit absoluten Pfaden gearbeitet wird!

$ mkdir ~/yocto && cd ~/yocto

Innerhalb dieses Verzeichnisses sollte man direkt auch einen gemeinsamen Downloadordner für die möglichen verschiedenen Systeme anlegen, dies erspart später mehrfaches Herunterladen der diversen Source Pakete. Wer ein entsprechendes Verzeichnis für derartige Downloads schon besitzt kann natürlich dieses auch per Symlink einbinden (oder in der späteren Konfiguration den entsprechenden Pfad angeben).

$ mkdir download

Zusätzliche Dateien

Die STLinux Boxen benötigen eine Firmware für den Audio- und Videodekoder! Diese sind nicht Bestandteil von Yocto oder der Recipes von seife! Diese Firmware kann aus der Originalfirmware kopiert werden oder man bemüht die Internet Suchmaschine seiner Wahl! Damit das Buildsystem komplette funktionsfähige Images erstellen kann benötigt man die audio.elf und die video.elf. Diese werden im Buildsystem über die Variable BINARY_STSLAVE_FW_PATH referenziert. Diese zeigt standardmäßig auf /data/stslave_fw/${MACHINE} was allerdings außerhalb des Homeverzeichnisses liegen würde. Wir können das Umschiffen indem wir die Firmware innerhalb des eben erstellten Downloadordners ablegen und später in der Konfiguration dies dem Buildsystem mitgeben. Da das Recipe auch noch die Zielplattform (spark) auswertet und dies an die Variable BINARY_STSLAVE_FW_PATH mit anhängt müssen wir nun innerhalb vom Ordner download/ noch einen Ordner spark/ erstellen und dort die Firmware ablegen.

$ mkdir download/spark
$ cp /Pfad/zu/audio.elf download/spark
$ cp /Pfad/zu/video.elf download/spark

Erstsetup Yocto für STLinux (Spark) Boxen

Da die benötigten Buildtools, die durch Yocto zur Verfügung gestellt werden, mit dem Vcs Git verwaltet werden, können wir diese einfach mit dem git Befehl klonen. Beim Yocto Projekt heißt der zugehörige Git Tree "poky" und es gibt noch zahlreiche weitere Git Tree's beim Yocto Projekt. Der aktuell als stabil geltende Branch von Yocto Poky heißt momentan 'krogoth' (Stand Juni 2017).
Um die möglichen verschiedenen Systeme lokal später auseinander halten zu können werden wir aber den Git Tree in ein anders benanntes Verzeichnis pullen, es empfiehlt sich den Treenamen von Upstream plus die benutze Plattform in die Benamung einfließen zu lassen. Für die ST basierten Boxen benutzt diese Anleitung den Namen 'yocto-poky-stl'.

Mit folgendem Befehl wird nur der Branch 'krogoth' vom Yocto Poky Projekt mit einer Tiefe von 1 Commit geklont und im Verzeichnis yocto-poky-stl abgelegt. In der Regel werden keine älteren Commits benötigt und man kann sich den Download dieser Informationen sparen, wer die komplette Historie benötigt lässt den Parameter --depth 1 weg.

$ git clone -b krogoth --single-branch --depth 1 http://git.yoctoproject.org/git/poky yocto-poky-stl

Nach dem erfolgreichen Auschecken wechselt man in das neue Verzeichnis.

$ cd yocto-poky-stl

HINWEIS:

Wer als OS ein Debian Stretch benutzt und das Paket python-html5lib installiert hat muss die Datei bitbake/lib/bs4/builder/_html5lib.py leider noch patchen. Der Branch 'krogoth' benutzt Python Module aus einer älteren Version von python-html5lib. Die nötigen Änderungen die durchzuführen sind findet man hier.

Zum Beispiel mit folgenden Einzeiler:

$ sed -i 's/treebuilders\._base\.TreeBuilder)/treebuilders\.base\.TreeBuilder)/g; s/treebuilders\._base\.Node)/treebuilders\.base\.Node)/g' bitbake/lib/bs4/builder/_html5lib.py

Auschecken der Neutrino-MP relevanten Git Tree's

Direkt nach dem Wechseln in das Verzeichnis müssen nun zwei weitere benötigte Git Verzeichnisse geklont werden die der Benutzer seife erstellt hat und pflegt. Dies geht recht einfach und gewohnt per git Kommando.

$ git clone https://github.com/seife/meta-stlinux.git
$ git clone https://github.com/seife/meta-neutrino-mp.git

Erstellen und Anpassen der Konfiguration

Dieser Schritt ist sehr wichtig da sonst keine Pakete und Images erstellt werden können, wir müssen quasi Yocto bekannt geben was es wie bauen soll. Ohne den folgenden Schritt hat unser System keine gültige Grundkonfiguration! Zum Erstellen einer allgemein gültigen Konfiguration führt folgende Zeile aus.

$ . ./oe-init-build-env build-stl

Dies sourced die Datei 'oe-init-build-env' und übergibt dieser als Argument 'build-stl', was, wie der Name schon vermuten lässt, unser Build Verzeichnis sein soll. Ihr solltet dabei folgenden Output sehen.

You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to, for
example, select a different MACHINE (target hardware). See conf/local.conf
for more information as common configuration options are commented.

You had no conf/bblayers.conf file. This configuration file has therefore been
created for you with some default values. To add additional metadata layers
into your configuration please add entries to conf/bblayers.conf.

The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
    http://www.openembedded.org/


### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
user@host:~/yocto/yocto-poky-stl/build-stl

Das Skript erstellt benötigte Variablen und erweitert auch die PATH Variable für die späteren Kommandos. Wenn Ihr obige Ausgabe nicht seht und ebenfalls auch nicht im Verzeichnis ~/yocto/yocto-poky-stl/build-stl steht habt Ihr etwas falsch gemacht!

Es müssen nun noch zwei weitere Anpassungen durchgeführt werden damit Pakete und Images erstellt werden können. Nachdem nun eine Grundkonfiguration vorhanden ist, muss diese um diverse Notwendigkeiten erweitert werden, wie zum Beispiel die Zielplattform oder weitere andere optionale Parameter. Dazu muss die Datei conf/local.conf (mit Sicht innerhalb des lokalen Verzeichnisses) angepasst werden. Folgende Zeilen erstellen die nötigen Information für das Yocto System. Achtung, bitte beachtet das die Variable DL_DIR mit dem richtigen Pfad ergänzt wird wenn nicht die Verzeichnisstruktur aus den obigen Punkten verwendet wird!

$ cat << EOF >> conf/local.conf

### DON'T CHANGE ANYTHING HERE UNLESS YOU KNOW WHAT YOU DOING!!!
### Config for STLinux based boxes
MACHINE = "spark"
### Prefered package system
PACKAGE_CLASSES = "package_ipk"
### Additional image feature, we want a package management
EXTRA_IMAGE_FEATURES += "package-management"
### Needed for using cached build informations
PRSERV_HOST = "localhost:0"

### Adopt these settings to your needs!
### Setup the seperate download folder here!
DL_DIR ?= "${HOME}/yocto/download"
### Setup a local mirror if wanted
#SOURCE_MIRROR_URL ?= "file:///home/[YOUR_USERNAME]/src/Archive"
### Uncomment if you want to use the mirror
#INHERIT += "own-mirrors"

## if you want to use ccache...
#INHERIT += "ccache"

## save some space by cleaning up after every build
#INHERIT += "rm_work"

### If you have the firmware {audio,video}.elf not in /data/stslave_fw/${MACHINE} ...
### then you can adjust the variable BINARY_STSLAVE_FW_PATH to a appropriate folder.
### Don't forget, the recipe is appending a ${MACHINE} (remind: we are using 'spark'!)
### later to the folder you adjust here!!!
BINARY_STSLAVE_FW_PATH="\${DL_DIR}"
EOF

Nun müssen Yocto die zusätzlichen Recipes (meta-stlinux und meta-neutrino-mp) noch bekannt gemacht werden. Diese Konfiguration erfolgt in der Datei conf/bblayers.conf. Mit folgendem Einzeiler kann man die nötigen zusätzlichen Recipes voll automatisiert einfügen.

$ sed -i -e "/meta-yocto-bsp/{p;s/meta-yocto-bsp/meta-stlinux/p;s/meta-stlinux/meta-neutrino-mp/}" conf/bblayers.conf

Damit ist Yocto vollständig konfiguriert und Ihr solltet folgende Verzeichnisstruktur von $HOME/yocto ausgehend besitzen:

user@host/yocto $tree -d -L 2
.
├── bitbake
│...
├── build-stl
│   ├── cache
│   ├── conf         <----- Ablageort für bblayers.conf und local.conf
│   ├── sstate-cache
│   └── tmp          <----- Verzeichnis in dem Neutrino-MP komplett gebaut wird
├── documentation
│...
├── meta-neutrino-mp
│...
├── meta-selftest
│...
├── meta-skeleton
│...
├── meta-stlinux
│...
├── meta-yocto
│...
├── meta-yocto-bsp
│...
└── scripts
 ...

Imageerstellung

Nach diesen Vorbereitungen kann dem Buildsystem mitgeteilt werden das man ein Neutrino-MP Image erstellt haben will. Eigentlich sind dies mehrere da Yocto verschiedene Images für einen USB-Stick und auch für den Flashspeicher der Boxen z.B. automatisch erstellt. Diese Erstellung stößt man über folgenden Befehl im Verzeichnis ~/yocto/yocto-poky-stl/build-stl an.

$ bitbake neutrino-image

Yocto beginnt nun die Recipies (dies sind die Regeln zum Bauen) zu parsen und den jeweiligen Zustand in eine lokale SQLite3 Datenbank zu schreiben. Dies kann auf klassischen rotierenden Festplatten mehrere Minuten dauern, SSDs sind hier deutlich schneller. Folgende Ausgabe sollte in etwa zu sehen sein. Alle fehlenden Quellpakete werden automatisch aus dem Internet geladen.

NOTE: Started PRServer with DBfile: /home/user/yocto/yocto-poky-stl/build-stl/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 36341, PID: 2713
WARNING: Host distribution "Debian-9.0" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
WARNING: /home/user/yocto/yocto-poky-stl/meta-stlinux/recipes-kernel/linux-firmwares/stslave-fw_0.1.bb: Unable to get checksum for stslave-fw SRC_URI entry audio.elf: file could not be found
WARNING: /home/user/yocto/yocto-poky-stl/meta-stlinux/recipes-kernel/linux-firmwares/stslave-fw_0.1.bb: Unable to get checksum for stslave-fw SRC_URI entry video.elf: file could not be found
Parsing recipes: 100% |#########################################################################################################################| ETA:  00:00:00
Parsing of 954 .bb files complete (0 cached, 954 parsed). 1401 targets, 233 skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION        = "1.30.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Debian-9.0"
TARGET_SYS        = "sh4-poky-linux"
MACHINE           = "spark"
DISTRO            = "poky"
DISTRO_VERSION    = "2.1.3"
TUNE_FEATURES     = "sh4"
meta              
meta-poky         
meta-yocto-bsp    = "krogoth:3565a9697f53ba975a1b7235b802f659418746c3"
meta-stlinux      = "master:a78cd89eb5bd96ada6578f38e29816ecbb13db28"
meta-neutrino-mp  = "master:942708152bf31ff6ca12cd29dcc0b293423e3781"

NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.0.1/x86_64-nativesdk-libc.tar.bz2;sha256sum=acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
Currently 4 running tasks (75 of 2150):
0: gcc-source-4.8.4-r1 do_fetch (pid 9495)
1: ncurses-native-6.0+20160213-r0 do_fetch (pid 10547)
2: xz-native-5.2.2-r0 do_configure (pid 24642)
3: gmp-native-6.1.0-r0 do_configure (pid 24709)

Die "WARNING" Ausgaben sind in gewisser Weise normal und bedeuten nicht unbedingt das ein Problem vorhanden ist. Wenn ein Fehler auftritt wird dieser mit "ERROR" markiert und es erscheint eine sehr ausführliche Meldung wo der Bau schief gelaufen ist mit zusätzlichen Angaben wo man die Logs zu diesem Vorgang findet. Beachtet in der Ausgabe die Branch Namen und SHA Summen der einzelnen Git Tree's, diese sind wichtig wenn man Probleme hat und sind bitte mit anzugeben wenn in einen der Foren z.B. nachgefragt wird.

Der Bau dauert je nach verfügbarer Anbindung ins Internet und Typ des Rechners teilweise mehrere Stunden wobei der längste Part das Kompilieren und Paketieren ist, auf einem i5 4x2,4GHz, 8GB RAM mit klassischer drehender Festplatte dauert es ca. 2h. Aus der obigen Ausgabe kann man auch entnehmen, dass insgesamt 2150 einzelne Schritte abgearbeitet werden müssen um die gewünschten Images gebaut zu erhalten.

Images und Pakete

Alles was Yocto gebaut hat liegt nach dem erfolgreichen Durchlaufen eines bitbake Befehls im Unterverzeichnis tmp/deploy.

$ tree -d -L 2 tmp/deploy/
tmp/deploy/
├── images
│   └── spark
├── ipk
│   ├── all
│   ├── sh4
│   └── spark
└── licenses
    ├── ...

Die diversen Images

Die erstellten Images liegen wie der Name des Verzeichnisses schon vermuten lässt in tmp/deploy/images/spark. Um die erstellten Images zu richtig verwenden zu können muss man verstehen wie die Images aufgebaut sind und welcher Typ verwendet worden ist.

Die Yocto Recipies erstellen Images für den Flashspeicher in den Boxen als auch für einen USB-Stick der sich mit einem modifizierten U-Boot benutzen lässt. Die Images sind voll funktionsfähig da Yocto die benötigte Firmawaredateien audio.elf und video.elf für die beiden DSPs mit in die Images integriert hat.

Die Sparkboxen können intern im Flash mit dem UBI Filesystem oder auch JFFS2 benutzt werden. Die jeweilige Benutzung ist fast eine Frage des persönlichen Geschmacks.

HINWEIS:

Bitte mit Infos ergänzen.

Durch die Eigenheit, dass das verwendete U-Boot keinen anderen Support als FAT16 für ein Filesystem eingebaut hat muss ein USB-Stick eine separate (1.) Partition für den Kernel besitzen, damit dieser vom U-Boot aus geladen und gestartet werden kann. Die zweite Partition kann mit ext3 oder ext4 formatiert sein. Um dies muss man sich aber nicht kümmern da Yocto ein komplettes ISO Image erstellt hat welches man auf den USB-Stick schreiben kann. Jedoch sind auch Archive mit den benötigten Dateien für die einzelnen Partitionen des USB-Sticks erstellt worden.

Folgende Dateien sind nun im Ordner tmp/deploy/images/spark zu finden.

Übersicht Dateien in tmp/deploy/images/spark

Dateiname	Typ	Verwendung
modules--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].tgz	Archiv	gepacktes Verzeichnis /lib/modules/* welches die Kernelmodule für den verwendeten Kernel enthält
modules-spark.tgz	Symlink	Link auf modules--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].tgz
neutrino-image-spark-[BUILD_DATE].rootfs.ext3	Image	2. Partition vom USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.jffs2.sum	Image	Image für Flashspeicher
neutrino-image-spark-[BUILD_DATE].rootfs.manifest	Manifest Datei	Installierte Pakete in den Images
neutrino-image-spark-[BUILD_DATE].rootfs.spark71xx-usbimg	Image	Komplett-Image für einen USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.tar.gz	Archiv	gepacktes Archiv mit den Dateien für die 2.Partition auf dem USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.ubi	Image
neutrino-image-spark-[BUILD_DATE].rootfs.ubifs	Image
neutrino-image-spark.ext3	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ext3
neutrino-image-spark.jffs2.sum	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.jffs2.sum
neutrino-image-spark.manifest	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.manifest
neutrino-image-spark.spark71xx-usbimg	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.spark71xx-usbimg
neutrino-image-spark.tar.gz	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.tar.gz
neutrino-image-spark.ubi	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ubi
neutrino-image-spark.ubifs	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ubifs
uImage	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin
uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin	Datei	SH4 Kernelimage ST7111 für 1. Partition auf dem USB-STick
uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin-7162	Datei	SH4 Kernelimage ST7162 für 1. Partition auf dem USB-STick
uImage-7162	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin-7162
uImage-spark.bin	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin

Schreiben auf einen USB-Stick

Um einen USB-Stick zu erstellen gibt es mehrere Möglichkeiten. Der bequemste und wohl auch schnellste Weg dürfte das Schreiben des Komplettimages auf einen USB-Stick sein. Dabei muss der USB-Stick mindestens 1GB groß sein (das Komplettimage ist größer als 512MB so das man die nächste größere Kapazitätsstufe benutzen muss). Mit dem Befehl dd und sudo Berechtigungen kann man das Komplettimage auf den USB-Stick schreiben. Zuvor muss in Erfahrung gebracht werden unter welchen Devicenamen der USB-Stick ansprechbar ist, dies ist z.B. mit dem Befehl dmesg möglich. Dann kann man wie folgend das Image auf den USB-Stick schreiben, vorausgesetzt man befindet sich immer noch im Verzeichnis ~/yocto/yocto-poky-stl/build-stl. Passt die Angabe von sd[x] entsprechend Euren Gegebenheiten an!

$ sudo dd if=tmp/deploy/images/spark/neutrino-image-spark.spark71xx-usbimg of=/dev/sd[x] bs=1MB

Beachtet bitte das der Schreibvorgang sehr wahrscheinlich durch das Betriebssystem gecached wird. Am besten vor dem Abstecken des USB-Sticks per sync Befehl sicher stellen das alle Daten geschrieben sind.

Der USB-Stick kann wie erwähnt sofort verwendet werden, sofern die U-Boot Einstellungen auf der Spark STB schon entsprechend angepasst worden sind, wie das geht findet man auf der Seite Spark:U-Boot. Der erste Boot in der STB dauert etwas länger und es wird eventuell auch automatisch rebootet sofern man eine ST7162 basierte Box benutzt da diverse Symlinks intern beim ersten Booten erstellt werden müssen.

Fehler und Probleme

Natürlich ist es fast unvermeidbar das an den diversen Stellen Probleme auftreten können. Dann ist eine manuelle Interaktion nötig. Hierzu folgende Hinweise.

Download einer Datei schlägt fehl

Da die diversen Server und Hosts, von denen die vielen benötigten Archive bezogen werden, nicht statisch sind und ständigen Veränderungen unterliegen wird folgendes Problem wohl bei jedem Benutzer von Yocto in ähnlicher Form irgendwann mal auftreten.

WARNING: giflib-5.0.5-r3 do_fetch: Failed to fetch URL http://downloads.sourceforge.net/giflib/giflib-5.0.5.tar.bz2, attempting MIRRORS if available
ERROR: giflib-5.0.5-r3 do_fetch: Fetcher failure: Fetch command failed with exit code 8, output:
20 redirections exceeded.

ERROR: giflib-5.0.5-r3 do_fetch: Function failed: Fetcher failure for URL: 'http://downloads.sourceforge.net/giflib/giflib-5.0.5.tar.bz2'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/user/yocto/yocto-poky-stl/build-stl/tmp/work/sh4-poky-linux/giflib/5.0.5-r3/temp/log.do_fetch.17481
ERROR: Task 760 (/home/user/yocto/yocto-poky-stl/meta-neutrino-mp/recipes-local/giflib/giflib_5.0.5.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1035 tasks of which 601 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
  /home/user/yocto/yocto-poky-stl/meta-neutrino-mp/recipes-local/giflib/giflib_5.0.5.bb, do_fetch
Summary: There were 13 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

Im Recipe für dieses Paket (hier giflib) sind diverse Quellen hinterlegt von denen Yocto versucht das Archiv giflib-5.0.5.tar.bz2 zu laden, jedoch kann dies mit keiner Quelle erfolgreich die Datei geladen werden. Das Projekt GifLib ist auf Sourceforce beheimatet und man findet dort auch eine Downloadseite für die Releases der Serie 5.x. Bei genauerer Betrachtung wird man erkennen, dass die Downloads auf dieser Seite per https angeboten werden, Yocto hat aber versucht das Archiv per http zu holen. Eigentlich sollte die Webserverkonfiguration auf Sourceforge automatisch einen Redirect auf https machen, die schlägt ab und an aber fehl. Dieses Problem kann auch bei anderen Servern und Archivdateien auftreten.

Das Problem lässt sich daher nur manuell lösen indem man die Datei von Hand von Sourceforge oder einem anderen Server lädt und in den Downloadordner ~/yocto/download ablegt. Zum Beispiel per wget.

$ wget -P /home/user/yocto/download/ https://downloads.sourceforge.net/giflib/giflib-5.0.5.tar.bz2

Danach stößt man den Build einfach an der unterbrochenen Stelle wieder an. Ihr solltet Euch immer noch im ursprünglichen Terminal aufhalten und im Verzeichnis ~/yocto/yocto-poky-stl/build-stl stehen, wenn nicht dann wieder in dieses Terminal und/oder Verzeichnis wechseln.

$ bitbake neutrino-image

Sollte es trotzdem wieder ein gleichlaufende Fehlermeldung geben dann hat Yocto seine Bau-Umgebung "vergessen". Dies ist aber einfach zu lösen indem man die Datei oe-init-build-env aus dem Verzeichnis /home/user/yocto/yocto-poky-stl wieder sourced und die Option build-stl mit übergibt. Danach kennt die Yocto Umgebung wieder alle Variablen für den Bau. Folgende Schritte sollten Abhilfe schaffen wen man eine fehlende Datei in den Downloadordner manuell gelegt hat und Yocto scheinbar nicht will.

$ cd /home/user/yocto/yocto-poky-st
$ . ./oe-init-build-env build-stl
$ bitbake neutrino-image