Aus Gentoo Linux Wiki

NSLU2 (Schrägansicht auf das Originalgehäuse)

NSLU2 (Detailliertes Bild der Platine)

Linksys, eine Tochterfirma von Cisco Systems hat vor einiger Zeit ein kleines Maschinchen basierend auf der embedded-arm Architektur herausgebracht, welches sich "NSLU2" nennt. Dieser Artikel soll einen Einblick in die Embedded-Welt geben, sowie Schritt für Schritt erklären, wie man Gentoo auf diesem Gerät zum Laufen bringt.

[Bearbeiten] Das Gerät

Linksys liefert das Gerät mit einem 2.4er kernel, Samba und einem entsprechenden Webinterface aus, damit man USB-Platten anschliessen kann, und diese per Webinterface-konfiguration über den Samba im Netzwerk freigeben kann. Dies ist zwar schön und gut - lässt für Erweiterungen jedoch wenig Spielraum. Es bedarf einer guten Distribution, welche auf unterschiedlichen Architekturen läuft. Was liegt näher, als hierfür Gentoo zu benutzen?

[Bearbeiten] Features

• Gerade mal ein bisschen kleiner als eine 3,5" Festplatte
• 100mbit Netzwerkschnittstelle
• 2 USB-Ports
• 266 mhz Prozessor
• 8 mb Flashspeicher
• 32 mb SD-Ram
• Unschlagbarer Preis von gerade mal 75€
• Sieht nicht schlecht aus

[Bearbeiten] Die CPU

Die NSLU2 wird mit einem Intel IXP420 als Prozessor ausgeliefert. Der XScale-Kern basiert auf der ARMv5TE Architektur und ist auf 266Mhz ausgelegt. Nichts desto trotz wird er in diesem Gerät nur mit 133 getaktet. Durch eine sehr einfache Modifikation kann man den Prozessor "deunderclocken". Wie man es anstellt ist hier zu sehen. Dies betrifft jedoch nur ältere Geräte, mittlerweile wird die CPU bereits bei Auslieferung mit 266 MHz getaktet, so dass dieser Schritt nicht mehr notwendig ist.

[Bearbeiten] Speicher

Die CPU ist angeschlossen an 8mb Flash-Speicher(0x50000000 - 0x50800000) Die 8MB Flash sind folgendermaßen aufgebaut:

• Start: 0x50000000, Länge: 0x40000 (256K) - der Bootcode
• Start: 0x50040000, Länge: 0x20000 (128K) - Systemkonfiguration (ich glaube für den bootmanager)
• Start: 0x50060000, Länge: 0x100000 (1MB) - Platz für den Kernel
• Start: 0x50160000, Länge: 0x6A0000 (6.625MB) - Das /-Dateisystem

Zudem gibt es 32MB SD-Ram, die unter folgender Adressspanne erreichbar sind: 0x00000000 bis 0x02000000. Es gibt die Möglichkeit, die Bausteine von ganz normalen SD-Ram Modulen zu nutzen, um damit den Speicher der NSLU2 aufzurüsten. Wie dies geht, sehr ihr hier.

[Bearbeiten] USB-controller

Das Gerät selbst hat 2 USB-Ports nach außen laufen. Der USB-Controller meldet sich in lspci als "USB Controller: NEC Corporation USB 2.0 (rev 04)"und wird problemlos von ohci/ehci unterstützt. Problemlos lässt sich auch ein aktiver USB-Hub anschliessen - aktiv daher, weil ich nicht glaube, dass der eigene USB der NSLU2 genügend Strom für viele Geräte liefert. Getestet habe ich den USB-Controller bisher mit 4 Festplatten im USB-Gehäuse und einem RFID-Reader welcher an einem Serial2USB-Converter hängt. Alles lief Problemlos, auch gleichzeitig.

[Bearbeiten] Netzwerk

Die Netzwerkschnittstelle wird direkt vom Prozessor bereitgestellt, und basiert damit auf dem IXP420 Chip, zu welchem man hier genauere Informationen findet. der Proprietäre Treiber dafür ist in Portage vorhanden und kann gegen den 2.6er Kernel gebaut werden.

[Bearbeiten] Bootloader

Ausgeliefert wird das Gerät mit dem Bootloader namens "RedBoot". Dieser genügt auch für unsere Zwecke und wir lassen ihn drauf. Obgleich es möglich ist, diesen durch den APEX Bootloader zu ersetzen.

[Bearbeiten] Serielle Schnittstelle

Das Gerät verfügt des weiteren über eine serielle Schnittstelle, welche jedoch nicht aus dem Gehäuse herausgeführt wird und zudem noch mit TTL-Pegel vorliegt. Daraus eine "echte" rs232-Schnittstelle zu machen ist kein Hexenwerk: Mann kann sich die Sachen entweder selbst zusammenlöten oder alternativ für einen erschwinglichen Preis die Komponente bei einem Distributor erwerben. Näheres dazu findet man hier. Ich empfehle jedem, diese serielle Schnittstelle zu nutzen und die entsprechenden Vorkehrungen (entweder den Adapter kaufen oder eben selbst löten) zu treffen, bevor man sich an die Internas der nslu2 wie beispielsweise den Bootloader wagt. Das debuggen des Bootprozesses ist ohne den seriellen Port nahezu unmöglich. Für die reine Installation von Gentoo auf einer externen Festplatte benötigt man dies zwar nicht, früher oder später ist man jedoch froh darüber, dass man die serielle Schnittstelle hat.

[Bearbeiten] Vorwort

Die NSLU2 (ich nenne sie liebevoll "sluggy") ist ein sehr beliebtes Gerät - unter anderem, weil Linksys von vorneherein Linux als Firmware ausgewählt hat, und für den Endbenutzer Modifikationen somit sehr leicht gemacht werden. Es haben sich auch schon sehr viele Leute daran gesetzt, für das Gerät (und auch für andere kleine embedded Geräte) eine Distribution zu bauen, welche dem Anspruch gerecht wird, auf vielen verschiedenen Architekturen und sehr "kleiner" Hardware zu laufen. Dabei rausgekommen ist unter anderem Openembedded. Openembedded ist ähnlich Gentoo eine "Source-Distribution", bietet viele Pakete und kompiliert diese auf einem "anderen" Rechner, und installiert sie dann mittels des Paketmanagers "ipkg" auf dem Gerät. Ich finde das in dem Sinne falsch, dass Openembedded die Gerät nicht als eigenständige Computer behandelt. Vielmehr als Endgeräte, die man sehr umständlich erst über einen anderen "richtigen" Rechner konfigurieren und einrichten muss. Dem ist jedoch nicht so! Selbstverständlich können wir unter Gentoo auch "cross-compilen" und ihr werdet sehen, dass ich dies auch im Laufe des Howtos tun werde, doch letztendlich behandle ich das Gerät wie einen ganz normalen Rechner - wie meinen Desktop-pc, meinen Laptop oder einen Root-server. Nichtsdesto trotz waren es Hauptsächlich die Leute von Openembedded und von nslu2-linux.org die Unmengen an Dokumentation für das Gerät geschrieben haben - ohne die ich selbst auch nicht so weit gekommen wäre. Vieles, was euch unklar erscheinen mag, oder was ich hier zu kurz beschreibe, wird dort im Wiki sehr ausführlich behandelt: Ein Blick dortrein lohnt sich!

[Bearbeiten] Was wollen wir?

Was ihr wollt, das weiss ich nicht. Ich für meinen Teil wollte jedoch auf dem kleinen Gerät ein vollständliges Gentoo laufen haben, auf dem ich nativ, ganz normal mittels Portage die Pakete emergen kann, die ich möchte. Desweiteren wollte ich (um unabhängig von den 8mb flash zu sein) eine große Festplatte haben, auf der mein Gentoo liegt.

[Bearbeiten] Also was brauchen wir?

• Zu aller erst brauchen wir mal eine Slug! Diese gibts bei ebay und ist auch bei Ramsch-seiten wie günstiger.de zu humanen Preisen zu finden. Inklusive Versand sollte man jedoch nicht mehr als 90€ hinblättern. Falsch machen kann man hierbei nichts. Es gibt zwar 2 Versionen der Slug, die unterscheiden sich jedoch lediglich (sehr) geringfügig im Platinenlayout - ergo: wo NSLU2 draufsteht, ist auch NSLU2 drin.
• Wie ein normaler Rechner braucht auch unsere Slug eine Festplatte. Ich verwende eine 160 gb Samsung IDE Platte in einem billigen USB-Gehäuse. Eine alte 20 gb Platte tut es jedoch auch alle Male, solange sie in ein USB-Gehäuse reinpasst, denn schliesslich hat die Slug keinen IDE-controller.
• Ein funktionierendes Netzwerk mit Routing ins Internet und einem freien Switchport für Sluggy.
• Einen zweiten Rechner, auf dem ein aktuelles Gentoo läuft.
• optional: Einen Wandler von TTL auf rs232, damit wir eine Serielle konsole haben, wenn wir arbeiten. Ein usb2serial-converter reicht nicht, da der bootloader beispielsweise garnicht den USB ansprechen kann. Der Bootloader, sowie der Bootvorgang des Linuxkernels können nur bei einem "echten" seriellen Anschluss "live" mitverfolgt und ggf. debuggt werden. Hier steht, wie man den seriellen Anschluss anbringt und hier kann man sich die vorgefertigte Platine für 24€ zukommen lassen (A232DBH3v).

[Bearbeiten] Wie gehen wir vor?

Um gentoo auf unserer Slug zu installieren gehen wir den gleichen Weg, wie das offizielle Installations-doku:

• Wir besorgen uns eine "live-cd", welche gebootet wird und von woaus wir alles weitere erledigen können.
• ...

[Bearbeiten] Installation

Wenn wir eine Festplatte in einem USB-gehäuse, sowie eine funktionstüchtige NSLU2 (im Idealfall mit fertiger serieller Schnittstelle) vor uns Liegen habe, kann es mit der Installation losgehen.

[Bearbeiten] Einrichten und Booten einer "Live-CD"

Linksys liefert die NSLU2 zwar von Haus aus mit einem Linux als Betriebssystem aus, auf dieses können wir jedoch nicht zugreifen. Daher benötigen wir ein funktionierendes Linux, von welchem aus wir bequem arbeiten können. Für diesen Zweck habe ich ein kleines System gebaut, welches die uclibc und busybox verwendet, dazu noch einen SSH-zugang mit bash und screen anbietet und auf einem linux-2.6.14.3er kernel läuft. Das Ganze passt bequem in den Flash-Speicher des Geräts und ist ohne viel Aufwand zu installieren.

Wir werden auf das System per ssh zugreifen. Wenn bei euch im Netzwerk die IP 192.168.1.2 noch nicht belegt ist, dann könnt ihr euch direkt das fertige Abbild des Rootdateisystems saugen:

wget http://nyrbs.de/~chilla/projekte/NSLU2/files/startup_image/nslu2-startup-image.tar.bz2 
wget http://nyrbs.de/~chilla/projekte/NSLU2/files/startup_image/nslu2-startup-kernel-2.6.14.3.zImage

wget http://nyrbs.de/~chilla/projekte/NSLU2/files/startup_image/nslu2-startup-image.tar.bz2
tar xvjpf nslu2-startup-image.tar.bz2
vim nslu2-startup-image/etc/inittab

null::sysinit:/sbin/ifconfig ixp0 192.168.1.2/24 up

emerge sys-fs/mtd
mkfs.jffs2 -d nslu2-startup-image --faketime -o nslu2-startup-image.jffs2 -pad --big-endian --eraseblock=0x20000

Nun brauchen wir eine Möglichkeit, das Rootdateisystem und den Kernel auf den Flashspeicher des Geräts zu übertragen. Genau dafür gibt es das hervorragende Tool namens "upslug2", welches sogar in Portage vorhanden ist.

echo "dev-embedded/upslug2 ~x86" > /etc/portage/package.keywords
emerge upslug2

Zu Testzwecken führen wir das Programm einfach mal kurz aus:

[19:25:49]|[chilla@chucky]|~$ upslug2
[no NSLU2 machines found in upgrade mode]

Erscheint diese Ausgabe, funktioniert alles. Aber wie unschwer zu erkennen ist, kann mit diesem Programm nicht automatisch auf die NSLU2 zugreifen - das Gerät muss erst in den "upgrade mode" versetzt werden. Um dies zu bewerkstelligen, ist folgendes zu tun:

• Sämtliche Geräte von der NSLU2 abschliessen, sodass nurnoch Netzwerk und Strom dranhängen.
• Dafür sorgen, dass die NSLU2 aus ist.
• Nun mit einem Kugelschreiber das Reset-knöpfchen auf der Rückseite des Geräts drücken und gedrückt halten!
• Bei gedrücktem Resetknopf den "power-button" kurz betätigen, und den Reset-knopf weiterhin gedrückt halten.
• ca. 10 Sekunden warten.
• Sobald das obere Lämpchen der NSLU2 auf rot wechselt, sofort den Reset-Knopf loslassen.
• Wenn die obere Lampe abwechselnd rot/grün blinkt, befindet sich das Gerät im Upgrade-modus. Falls nicht, die ganze Prozedur nochmals durchführen.

Um zu überprüfen, ob die NSLU2 auch wirklich im "upgrade-modues" ist, führen wir einfach nochmal "upslug2" aus und sollte folgende Ausgabe sehen:

[19:37:38]|[chilla@chucky]|~$ upslug2
NSLU2     00:13:10:d6:1d:f2 Product ID: 1 Protocol ID: 0 Firmware Version: R23V29 [0x2329]

Erscheint diese Ausgabe, können wir das Startupsystem in den Speicher der NSLU2 übertragen:

upslug2 --rootfs=nslu2-startup-image.jffs2 --kernel=nslu2-startup-kernel-2.6.14.3.zImage

Falls ihr mehrere NSLU2s im Netzwerk und auch zufällig gleichzeitig im Upgrademodus habt, müsst ihr noch die Mac-Adresse mit angeben:

upslug2 --rootfs=nslu2-startup-image.jffs2 --kernel=nslu2-startup-kernel-2.6.14.3.zImage --target=0:13:10:d6:1d:f2

Nun wird das Rootdateisystem und das Kernelimage auf die NSLU2 übertragen, folgende Ausgabe sollte zu sehen sein:

[19:42:38]|[chilla@chucky]|~/tmp/slughowto$ upslug2 --rootfs=nslu2-startup-image.jffs2 --kernel=nslu2-startup-kernel-2.6.14.3.zImage
NSLU2     00:13:10:d6:1d:f2 Product ID: 1 Protocol ID: 0 Firmware Version: R23V29 [0x2329]
Upgrading LKGD61DF2 00:13:10:d6:1d:f2
   . original flash contents  * packet timed out
   ! being erased             - erased
   u being upgraded           U upgraded
   v being verified           V verified

 Display:
   <status> <address completed>+<bytes transmitted but not completed>
 Status:
   * timeout occured          + sequence error detected

 7fffff+000000 ...VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
Rebooting... done

Wie bereits in der Ausgabe beschrieben steht, bootet die NSLU2 nun durch und sollte kurz darauf auch per ssh erreichbar sein:

ssh root@192.168.1.2

Das Root-passwort lautet für dieses Image "nslu2". Nachdem wir uns eingeloggt haben, ist es geschafft: ein voll funktionstüchtiges Linuxsystem ist auf unserer NSLU2 gebootet, auf welches wir per ssh zugreifen können.

Was haben wir getan? Wir haben nichts anderes getan, als die standard linksys firmware von dem Gerät verbannt, einen Linuxkernel in den Speicherbereich 0x50060000++ und unser /-Verzeichnis (auf einem JFFS2-Dateisystem) in den Speicherbereich 0x50160000++ gesetzt und neu gebootet. Der Bootloader bemerkt den Kernel dort automatisch. Die Commandline ist fest in den Kernel einkompiliert - somit weiss der Kernel auch, dass er die Partition /dev/mtdblock4 (das ist der Speicherbereich des Rootdateisystems) als JFFS2-Dateisystem nach / mounten, und dort /sbin/init ausführen soll. /sbin/init rödelt die /etc/inittab durch, in dieser steht geschrieben, dass er einige Sachen mounten soll, das Modul für die Netzwerkkarte laden soll, Netzwerkeinstellungen machen soll und den ssh-server starten darf. Der Kernel, den ich hierbei verwende hat support für ein ext3-dateisystem und USB-storage - somit können wir im nächsten Schritt unsere Festplatte anschliessen und dort unser richtiges Gentoo bauen.

Wie man ein solches kleines System für die NSLU2 baut, um es als Rescue-system oder auch als Hauptsystem zu nutzen, wenn man keine Festplatte anschliessen möchte, erfahrt ihr hier.

[Bearbeiten] Einrichten einer Festplatte

Wenn bei der Übertragung des Startup-images nichts schief gegangen ist und ihr die NSLU2 durchgebootet habt (was sie ja eigentlich nach der übertragung automatisch machen sollte), ist sie binnen kurzer Zeit wieder per ssh unter der ip 192.168.1.2 (oder gegebenenfalls unter der angepassten IP) erreichbar. Einloggen könnt ihr euch auf das System als root mit dem Passwort "nslu2". Schliesslich im System angekommen geht es nun an die Einrichtung einer Festplatte. Ich empfehle euch hierfür wärmstens, erstmal eine Screensession zu starten, nicht dass längere emerge-Vorgänge auf einmal abgebrochen werden, weil das Netzwerkkabel rausrutscht oder etwas ähnlich blödes passiert:

screen

Von einem anderen Rechner aus könnt ihr euch dann jederzeit wieder per ssh auf die NSLU2 einloggen und dort mit "screen -r" die screen-session wieder herholen.

Die Festplatte, welche wir als Datenträger für unser Rootdateisystem nutzen möchten sollte in einem USB-Gehäuse sitzen und nun an die NSLU2 angeschlossen werden. Ein paar Sekunden später erscheint in dmesg in etwa folgende Ausgabe:

root@gentooslug ~ # dmesg | grep sd
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: assuming drive cache: write through
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: assuming drive cache: write through
 sda: sda1 sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

In meinem Fall ist die Platte schon partitioniert - ihr müsst dies gegebenenfalls entsprechend der offiziellen Installationsdoku nachholen (fdisk ist in dem Startup-system, welches ihr gerade nutzt vorhanden). Achtet hierbei darauf, dass ihr mindestens 500mb Swap einrichtet, wenn nicht sogar 1-2gb, da die maschine nur 32mb Ram hat und man sonst probleme beim Kompilieren bekommt. Desweiteren ist In dem Startupsystem momentan nur ext2-Support eingebaut. Dementsprechend solltet ihr auch ersteinmal das Rootdateisystem nur als ext2 formatieren, als ext3 könnt ihr es später immernoch umwandeln, wenn ihr dies wollt. Meine Partitionierung sieht folgendermaßen aus:

root@gentooslug ~ # fdisk -l /dev/sda

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes 

   Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *           1        2432    19535008+  83  Linux
/dev/sda2            2433        2554      979965   82  Linux swap

Und entsprechend formatiere ich die Partitionen:

mkfs.ext2 /dev/sda1
mkswap /dev/sda2

Nun mounten wir die Partition, die unser Rootdateisystem beherbergen soll nach /mnt/gentoo, mounten dort auch noch /proc /dev und schmeissen die Swap-partition an.

mount /dev/sda1 /mnt/gentoo
mkdir /mnt/gentoo/proc
mount -t proc none /mnt/gentoo/proc
mount --bind /dev /mnt/gentoo/dev
swapon /dev/sda2

[Bearbeiten] Herunterladen von Stage-tarball und Portage-snapshot

Die nächsten paar Schritte sind für versierte Gentoo-Anwender bekannte Arbeit: Wir besorgen uns einen Stage-tarball und einen Portage-snapshot, und chrooten in unsere neue Umgebung. Ein paar pfiffige Jungs vom embedded-gentoo-Projekt haben bisher große Arbeit geleistet, denn sie haben uns einen funktionsfähigen Stage3-Tarball erschaffen, welcher mit der NSLU2 kompatibel ist, da er für xscale-Prozessoren kompiliert und big-endian Binaries erzeugt. Den Stagetarball findet man auf fast jedem Gentoo-mirror, welchem man sich aus Liste ersteinmal aussuchen sollte. Auf unserem gewünschen Gentoo-spiegel angekommen überprüfen wir, ob er unseren Stagetarball im Verzeichnis /experimental/arm/embedded/stages/ beherbergt und kopieren den Link zur Datei stage3-armeb-uclibc-softfloat-2005.1.tar.bz2 und laden diese auf unserer NSLU2 mit wget runter.

echo "nameserver 192.168.1.1" > /etc/resolv.conf
cd /mnt/gentoo
wget http://ftp.uni-erlangen.de/pub/mirrors/gentoo/experimental/arm/embedded/stages/stage3-armeb-uclibc-softfloat-2005.1.tar.bz2

Was wir uns auch gleich noch von diesem Mirror besorgen ist ein Portage-snapshot:

wget http://ftp.uni-erlangen.de/pub/mirrors/gentoo/snapshots/portage-latest.tar.bz2

Diese beiden entpacken wir ebenfalls gemäß der offiziellen Dokumentation

tar xvjpf stage3-armeb-uclibc-softfloat-2005.1.tar.bz2
tar xjf portage-latest.tar.bz2 -C /mnt/gentoo/usr

Und nun ist es soweit, wir chrooten in unser neues System und arbeiten von dortaus weiter, zuvor muss aber die resolv.conf in das neue System kopiert werden.

cp /etc/resolv.conf /mnt/gentoo/etc/
chroot /mnt/gentoo /bin/bash

[Bearbeiten] Einrichtung des Basissystems

Nach dem chroot befinden wir uns in unserem neuen Rootverzeichnis. Dies ist zwar schön und gut, doch nun gilt es, dieses System lauffähig und auf einen aktuelleren Stand zu bringen. Das Stagearchiv, welches wir hier verwenden, benutzt noch den gcc 3.3 und ist ausgelegt auf einen 2.4er Kernel mit devfsd. Somit gibt es nun für uns noch ein paar kleine Änderungen in den Konfigurationen zu machen und schliesslich das System upzudaten.

Zu Begin widmen wir uns Portage und seinem Profil. Dieses werden wir auf " /usr/portage/profiles/uclibc/arm/" festlegen:

rm /etc/make.profile
ln -s /usr/portage/profiles/uclibc/arm/ /etc/make.profile

Nun müssen wir die /etc/make.conf anpassen, denn sonst werden die Programme nicht richtig kompiliert und sind auf unserem System nicht lauffähig. Die /etc/make.conf sollte folgendermaßen aussehen:

bgentooslug / # cat /etc/make.conf
CFLAGS="-march=armv5t -Os"
CHOST="armeb-softfloat-linux-uclibc"
CXXFLAGS="-march=armv5t -Os"
USE="pam -bitmap-fonts -truetype-fonts -type1-fonts -expat"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
RSYNC_TIMEOUT=500
FEATURES="ccache -noman -noinfo -nodoc"
UCLIBC_CPU="ARM_XSCALE"

Ein emerge --info bestätigt uns nun, dass wir Portage richtig konfiguriert haben:

gentooslug / # emerge --info
Portage 2.0.51.22-r2 (uclibc/arm, gcc-3.4.4, uclibc-0.9.27-r0, 2.6.14.3 armv5teb)
=================================================================
System uname: 2.6.14.3 armv5teb XScale-IXP42x Family rev 1 (v5b)
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.16-r1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.4.26-r1
ACCEPT_KEYWORDS="arm"
AUTOCLEAN="yes"
CBUILD="armeb-softfloat-linux-uclibc"
CFLAGS="-march=armv5t -Os"
CHOST="armeb-softfloat-linux-uclibc"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=armv5t -Os"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="arm bzip2 ncurses pam perl python readline uclibc zlib userland_GNU kernel_linux elibc_uclibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAYWas

Wir legen eben noch den Nameserver fest, damit wir Domainnamen auflösen können und legen dann auch schon los und lassen uns mal anzeigen, was Portage uns denn so alles anbietet, zum updaten:

echo "nameserver 192.168.1.1" > /etc/resolv.conf
emerge -puvDN world

Dies sollte eine relativ lange Liste sein. Doch wir stellen fest, dass dort einige Pakete dabei sind, die wir auf keien Fall brauchen werden, da wir sie entweder garnciht benötigen oder eine Alternative verwenden. Diese Pakete könnnen wir vor dem grußen Systemupdate getrost unmergen:

emerge -C busybox dropbear devfsd

Danach gehts rund: wir updaten unser System, stellen es damit auf unser neues Profil und die neue make.conf ein. Dies kann sehr lange dauern - es ist also angeraten, für eine andere Beschäftigung zu sorgen.

emerge sync
emerge -uDN world
etc-update

Ich selbst habe die NSLU2 jetzt ersteinmal 2 Tage stehen lassen. Habe auch, ehrlich gesagt, nicht nachgeschaut wie lange sie nun letztendlich für das Systemupdate gebraucht hat. Nun sind 2 Tage vergangen und das update ist vollständig ohne Fehler durchgelaufen. Da das System komplett neu ist, kann ich etc-update getrost mit der anweisung "-5" alle updates automatisch einspielen lassen, ohne dass ich jedes extra bestätigen muss.

[Bearbeiten] Der Kernel

Nun werden wir uns an den Kernel setzen. Wir verwenden einen normalen Linuxkern mit offenen Quellen. Diesen werden wir genauso kompilieren, wie wir es auf unserem normalen Rechner auch tun würden. Es gibt keinen vernünftigen Grund, den original Linksyskernel zu benutzen oder sich von diversen anderen Projekten binäre Kernelmodule über einen Paketmanager nachzuinstallieren. Wenn wir später irgendeine zusätzliche Hardware an die NSLU2 anschliessen wollen (beispielsweise eine Webcam), dann wollen wir ganz einfach nach /usr/src/linux wechseln, dort menuconfig aufrufen und unsere gewünschte Hardware als Modul auswählen und dieses kompilieren. Es gibt natürlich auch die Möglichkeit des crosskompilierens - ich halte das jedoch in diesem Fall für totalen Quatsch. Um einen Kernel bauen zu können, brauchen wir natürlich ersteinmal seine Quellen. Diese holen wir uns mit

emerge vanilla-sources

Und nun stoßen wir auf ein paar kleine Problemchen. Die NSLU2 hat gewisse Hardware, die wiederunm gewissen Patches brauch, damit sie läuft. Mit diesen Patches müssen wir sie natürlich füttern - jedoch sind die Patches immer Versionsabhängig. Ich nehme mir die Patches einfach vom [1] Projekt, denn wenigstens in diesem Punkt leisten sie gute Arbeit und stellen brauchbare Patches bereit. Nun erstelle ich erstmal Symlinks und Verzeichnisse:

cd /usr/src
rm linux
ln -s linux-2.6.15.1 linux
cd linux
mkdir patches

.. to be continued ..

Noch nicht ausformuliert:
echo "nameserver 192.168.1.1" > /etc/resolv.conf
wget http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/experimental/arm/embedded/stages/stage3-armeb-uclibc-softfloat-2005.1.tar.bz2
cd /mnt/gentoo
tar xvjpf bla
wget portage-snapshot
tar xjf bla -C /usr/
mount -t proc none /mnt/gentoo/proc
chroot
echo "nameserver bla" > /etc/resolv.conf
rm /etc/make.profile 
ln -s /usr/portblabla /etc/make.profile
vi /etc/make.conf
emerge sync
emerge -puvDN world; -uDN world;
emerge openssh screen
emerge vanilla-sources
emerge ixp4xx
vi /etc/configsbla
reboot bla