Embedded Gentoo – Tagebuch eines Versuchs (Teil 1)

Das Ziel dieser Übung ist, ein System welches sich leicht warten lässt mit minimaler Grösse zu erstellen. Da Gentoo Linux meine Lieblingsdistribution ist und dank CHROOT() nicht viel schief gehen kann, starte ich einen Versuch in einem lokalen Build-Verzeichnis.

Nach erstellung eines Verzeichnisses lade ich die Stage-1 des Gentoo-Embedded Projekts, welche noch immer als sehr experimentell gilt. Man findet sie unter den Gentoo-Mirrors unter experimental/x86/embedded/stages. Da Stage-1 ein Compile von der Pike auf wird, das heisst mit Bootstrap – wird es auch die meiste Zeit in Anspruch nehmen, mir jedoch die Möglichkeiten offen lassen, auf anderen Architekturen zu arbeiten.

Nach dem Entpacken der Stage kopiere ich die benötigen Dateien und mounte mir Filesysteme. Da mein Portage auf einer eigenen Partition liegt binde ich ihn ein, halte ich jedoch PORTAGE_PKG und PORTAGE_DISTDIR in getrennten Verzeichnissen ausserhalb dieser Partition um mein Echtsystem nicht unnoetig mit Fremdpaketen zu belasten. Um trotzdem nichts doppelt aus dem Netz downloaden zu müssen verwende ich den ohnehin schon existierenden HTTP-Replicator, welcher im lokalen Netz läuft:

* net-proxy/http-replicator
Available versions: 3.0
Installed: none
Description: Proxy cache for Gentoo packages

Ich binde ihn in die make.conf des Target-Systems ein. Der Eintrag dazu lautet: http_proxy=“http://http_replicator.localnet.net:8080″

Als Kernel habe ich mich für die Version 2.6.xx entschieden – weshalb ich den Symlink von make.profile neu setzen muss. Diese Version ist zwar grösser, aber sie entspricht jeder auf meinem Build-Host.

Was bisher geschah:

mkdir /mnt/gentoo_uclib
cd /mnt/gentoo_uclibc
wget <path to stage-file>
tar xjpf <stage-file>
cp -L /etc/resolv.conf /mnt/gentoo_uclibc/etc/resolv.conf

mkdir -p /mnt/gentoo_uclibc/usr/portage

im chroot selbst:

mkdir /usr/local/portage
mkdir /var/log/portage
env-update
source /etc/profile
ln -snf /usr/portage/profiles/uclibc/x86/2005.1 /etc/make.profile
emerge ccache -av
ccache -M 2G

Die abgeänderte make.conf meines chroots sieht wie folgt aus:

# Build-time functionality
# ========================
USE="minimal buildpkg"

# Host Settings
# =============
# CHOST=“i686-pc-linux-gnu“
CFLAGS=“-march=i686 -pipe -Os“

# Advanced Masking
# ================
#ACCEPT_KEYWORDS=“~x86″
ACCEPT_KEYWORDS=“x86″

# Portage Directories
# ===================
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/usr/portage
DISTDIR=/usr/local/portage/distfiles
PKGDIR=/usr/local/portage/packages
PORT_LOGDIR=/var/log/portage

PORTDIR_OVERLAY=“/usr/local/portage“

# Fetching files
# ==============
http_proxy=“http://http_replicator.localnet.net:8080″

# Synchronizing Portage
# =====================
SYNC=“rsync://rsync.gentoo.org/gentoo-portage“
RSYNC_RETRIES=“3″
RSYNC_TIMEOUT=180

# Advanced Features
# =================
EMERGE_DEFAULT_OPTS=““
MAKEOPTS=“-j2″
AUTOCLEAN=“yes“
PORTAGE_TMPFS=“/dev/shm“

FEATURES=“autoconfig buildpkg ccache confcache digest distlocks fixpackages sandbox sfperms strict usersandbox“
CCACHE_SIZE=“2G“
# DISTCC_DIR=“${PORTAGE_TMPDIR}/.distcc“
# UNSERMAKE=“/usr/bin/unsermake“

# Hardware specific
# =================
# ALSA_CARDS=“intel8x0″

So weit so gut. Ich befinde mich im chroot meines Embedded-Stage1 Systems und kann nun mit dem Bootstrap beginnen, was sich aber nicht ganz nach Handbuch bewerkstelligen lässt:

embedded portage # scripts/bootstrap.sh -f
bash: scripts/bootstrap.sh: /bin/bash: bad interpreter: Permission denied

Also dann, ein bisschen direkter, indem wir sie mit passendem Interpreter aufrufen – bash scripts/bootstrap.sh – und der Prozess nimmt seinen Lauf…

Spätestens jetzt sollte man sich über eine Beschäftigung gedanken gemacht haben, wie zum Beispiel Aufräumen, Howtos schreiben – kurz gesagt etwas, das einen für die nächsten Stunden bei Laune hält bis schliesslich auch der nächste Schritt, das ‚emerge -e system‚ gelaufen ist.

Author:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert