229 lines
12 KiB
Plaintext
229 lines
12 KiB
Plaintext
![]() |
#Framework, welches ein komplettes Linux System aus den Sourcen erstellt
|
|||
|
#dieses Framework wird im CVS Repository
|
|||
|
#:pserver:cvs.tramp-bbs.de:/opt/cvs zur Verf<72>gung gestellt
|
|||
|
#
|
|||
|
#Lage dieser Datei im Archiv: $HeadURL$
|
|||
|
#
|
|||
|
#(c) 2003 Harald Kueller, Germany
|
|||
|
#This program is free software; you can redistribute it and/or
|
|||
|
#modify ist under the terms of the GNU General Public License
|
|||
|
#as published by the Free Software Foundation; either version
|
|||
|
#2 of the License, or (at your option) any later version.
|
|||
|
#
|
|||
|
#This program is distributed in the hope that it will be useful,
|
|||
|
#but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|||
|
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
#See the GNU General Public License for more details.
|
|||
|
#
|
|||
|
#You should have received a copy of the GNU General Public License
|
|||
|
#along with this program; if not write to the Free Software Foundation,
|
|||
|
#Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|||
|
#
|
|||
|
#Beschreibung:
|
|||
|
#Gundanleitung zur Erzeugung des Linux Systems
|
|||
|
#
|
|||
|
#Letzte <20>nderung von: $Author$
|
|||
|
#Datum der letzten <20>nderung: $Date$
|
|||
|
#Version der Datei: $Revision$
|
|||
|
#
|
|||
|
|
|||
|
Einleitung
|
|||
|
|
|||
|
Die Erstellung eines Linux Systems basiert auf 4 Schritten.
|
|||
|
Im 1. Schritt wird, aus einer laufenden Linux Installation heraus, ein
|
|||
|
Cross Compiler Setup gebaut, mit dem die Software passend fuer die gewuenschte
|
|||
|
Zielplattform gebaut werden kann. (crosschain)
|
|||
|
Im 2. Schritt werden, mit Hilfe der vorher erzeugten cross tool Chain, die glibc,
|
|||
|
sowie alle fuer ein Grundsystem notwendigen tools, passend fuer die Zielplatform,
|
|||
|
erzeugt (toolchain).
|
|||
|
Im 3. Schritt wird dann ein Basis System, das kompett bootfaehig ist, und alle
|
|||
|
notwendigen UNIX-Utilities nebst Kompiler und Development tools enthaelt.
|
|||
|
Dieses System stellt bereits eine komplette UNIX Umgebung zur Verfuegung.
|
|||
|
Im 4. Schritt werden nun aus dem frisch erzeugten UNIX (GNU/Linux) Grund System
|
|||
|
heraus alle tools, libs und applikationen gebaut, die den Umfang von UNIX/Linux
|
|||
|
ausmachen.
|
|||
|
|
|||
|
Daraus ergibt sich die Notwendige Umgebung, um das Linux System zu Bauen:
|
|||
|
1. Es wird eine Lauffaehige Linux Installation mit Compiler benoetigt.
|
|||
|
2. Das System muss einen funktionsfaehigen Internetzugang haben!
|
|||
|
Dieser wird benoetigt, um diverse Zusaetze zu den Packeten (init scripten
|
|||
|
etc. ) von svn://svn.compuextreme.de/ aus dem Subversion Archiv zu holen
|
|||
|
3. Es wird ein Verzeichniss mit genuegend Platz (ca 3 GB) benoetigt
|
|||
|
4. Nach erstellung der toolchain, und dem chroot in dieses System
|
|||
|
Muessen von diesem System aus die Source Dateien zur Verfuegung stehen.
|
|||
|
|
|||
|
Die Automatische Generierung des Viitor Systems
|
|||
|
Bevor mit der Automatischen Generierung des Systems begonnen werden
|
|||
|
kann, muessen die Vorraussetzungen erfuellt werden - d. H. es muss ein
|
|||
|
Verzeichniss, oder besser eine Partition erstellt werden, in welchem die
|
|||
|
Generierung des Systems stattfinden soll.
|
|||
|
Nun kann aus dem ViitorMake projekt (in dessem Root Direktory) ein
|
|||
|
Scripts/initViitorMake gestartet werden. Dieses schreibt den Pfad zu
|
|||
|
ViitorMake nach $HOME/.ViitorMake, und laed dann das File
|
|||
|
defsys in einen Editor. Dieses muss nun angepasst werden.
|
|||
|
|
|||
|
Hier werden folgende Variablen eingestellt:
|
|||
|
|
|||
|
VERSION - Version des zu erzeugenden Viitor Systems.
|
|||
|
CPU - Kuerzel fuer die Ziel Platform CPU (P,PII,PIII,K7,XP,K8,K8_62,sparc64)
|
|||
|
ueber die CPU Einstellung werden direkt die BUILDOPTIONS, also
|
|||
|
die verwendeten Compiler Optimierungen eingestellt!
|
|||
|
LFS - Pfad zum Verzeichniss, in welchem die Distribution installiert
|
|||
|
werden soll
|
|||
|
SRCDEV - Geraet (z.B. NFS Pfad), auf welchem die SOURCE Dateien der
|
|||
|
Distribution liegen
|
|||
|
SRCMNTPOINT - Zielmountpoint, der verwendet werden kann, um SRCDEV zu
|
|||
|
mounten
|
|||
|
LFSSOURCE - Pfad zu den Source Archiven (fuer Dynamisches System - muss
|
|||
|
unter $SOURCEDEV/$LFSSOURCE zu finden sein!)
|
|||
|
Dieser Pfad muss alle Dateien die in der Datei SRCLIST
|
|||
|
aufgelistet sind enthalten. Dabei ist die Versionsnummer
|
|||
|
dieser Dateien weitestgehend unbedeutend, jedoch muss
|
|||
|
ein Entsprechende Source Code Archive vorhanden sein!
|
|||
|
SOURCE - Pfad zu den Source Archiven (fuer statisches System)
|
|||
|
MAKEDIR - Pfad in welchem Platz fuer das Enpacken Source Dateien und
|
|||
|
den Make Prozess ist. Typischerweise /usr/src
|
|||
|
TMPROOT - Pfad, unter welchem die Dynamsichen Packete installiert
|
|||
|
werden koennen (make DESTDIR=$TMPROOT install - damit von
|
|||
|
dort aus die Packete erstellt werden koennen.
|
|||
|
DISTTARGET - Pfad zu den Binarys der Viitor Distribution - hier werden
|
|||
|
die Uebersetzten Packete als *.tbz eingespielt
|
|||
|
SVNURL - Lage des Subversion Repositorys. wird benoetigt um zusaetzliche
|
|||
|
Daten (Configs, Scripten wie z.B. die init scripten etc) zu holen
|
|||
|
PATTERN - Wird intern von genpkg verwendet. Nur fuer Entwickler von
|
|||
|
bedeutung, die einzelne Module, oder an genpkg
|
|||
|
weiterentwickeln
|
|||
|
|
|||
|
Nach dem diese Variablen Angepasst sind, das file speichern und den Editor verlassen.
|
|||
|
Damit beendet sich initViitorMake.
|
|||
|
Nun kann der Make Prozess angeworfen werden:
|
|||
|
|
|||
|
cd BaseBuild
|
|||
|
./makeViitor
|
|||
|
|
|||
|
Dieses Script generiert erst alle Module aus dem crosschain Verzeichniss. Hier erfolgt die
|
|||
|
Installation nach $LFS/cross-tools und $LFS/tools. Danach werden alle Module aus toolchain
|
|||
|
gebaut, die nach $LFS/tools installiert werden. Naja tatsaechlich jeweils nach
|
|||
|
/tools und /cross-tools, welche aber von makeViitor als Soft link auf $LFS/tools
|
|||
|
und $LFS/cross-tools angelegt werden.
|
|||
|
Ist die toolchain so fertig gebaut, erzeugt makeViitor in $LFS/root/.bash_profile
|
|||
|
anweisungen, die nach einem chroot nach $LFS dafuer sorgen, das
|
|||
|
/usr/src/ViitorMake/BaseBuild/makeall aufgerufen wird, welches dann die Module
|
|||
|
in testchain (tools, die benoetigt werden um einen "make check" auszufuehren.),
|
|||
|
und anschliessen alle Module unter Basesys durchlaeuft.
|
|||
|
Die Reihenfolge der Module, sowie welche tatsaechlich abgearbeitet werden, wird
|
|||
|
jeweils in crosschain/crosschain.dmk, toolchain/toolchain.dmk, testchain/testchain.dmk
|
|||
|
und Basesys/Basesys.dmk konfiguriert.
|
|||
|
Ist makeViitor, bzw makeall mit seiner Arbertig, liegt in DISTDIR eine lauffaehige
|
|||
|
ViitorLinux Version. Nun kann $LFS geloescht werden, und die neu erzeugte Version
|
|||
|
nach $LFS installiert werden:
|
|||
|
|
|||
|
cd $DISTDIR/install
|
|||
|
make_base_install -c BaseDevel.cfg -m $LFS
|
|||
|
|
|||
|
Die chroot Umgebung kann sofort wieder verlassen werden. Wichtig ist hier nur,
|
|||
|
das $LFS/etc/resolv.conf sowie $LFS/etc/nsswitch.conf so angepasst werden, das
|
|||
|
das Subversion Repository nach einem chroot $LFS erreichbar bleibt.
|
|||
|
Weiterhin muss der Mountpoint fuer die Viitor Source Files unter $LFS angelegt werden.
|
|||
|
Danach kann mit Scripts/initChroot wieder in das neu installierte ViitorSystem gewechselt
|
|||
|
werden.
|
|||
|
Nun das ViitorMake Projekt neu aus dem Repository holen, und konfigurieren.
|
|||
|
|
|||
|
Nun kann das Komplette System (Step 4) mit dem Aufruf:
|
|||
|
|
|||
|
cd SysBuild
|
|||
|
../genpkg -c DistCluster.dmk
|
|||
|
|
|||
|
erzeugt werden.
|
|||
|
|
|||
|
|
|||
|
Hinweise fuer Entwickler
|
|||
|
|
|||
|
Die Funktionalitaet der Scripten basiert auf den Scripts dynsys/makedynpkgr
|
|||
|
und staticsys/makestaticinst. Diese Scripten werten $1 (1. Argument) aus,
|
|||
|
Die Funktionlitaet der Scripten beruhen alle auf dem genpkg Script im Root Direktory
|
|||
|
des ViitorMake Projekts. Dieses Soruced jeweils eine Datei (Name kommt aus *.dmk files,
|
|||
|
oder als argument auf der commandozeile) ein. In diesen Files m<>ssen
|
|||
|
die Funktionen premk(), mk() und postmk() existieren.
|
|||
|
Der weitere Ablauf gestaltet sich folgendermassen:
|
|||
|
SRCPATH wird definiert.
|
|||
|
SRCPATH - Die Variable definiert den restlichen Pfad zum Soiurcearchiv.
|
|||
|
nun wird in $MAKEPATH oder /usr/src das Archive
|
|||
|
$LFSSOURCE/$SRCPATH/$PROGNAME* entpackt. Weiterhin wird <20>berpr<70>ft, ob zu
|
|||
|
dem sourcearchiv ein patch file existiert (gleichername.patch.pack) wird
|
|||
|
dieser Patch in die Sourcen eingespielt.
|
|||
|
Danach wird in das neue Verzeichniss gewechselt und die Funktionen
|
|||
|
premk()
|
|||
|
mk()
|
|||
|
postmk()
|
|||
|
in genau dieser Reihenfolge aufgerufen.
|
|||
|
Diese drei Funktionen muessen aus den Sourcen die BINARYS Bauen, und nach
|
|||
|
$TMPROOT installieren. Die dort hinterlegten Files werden nun zu einem
|
|||
|
Viitor Package zusammengeschnuert, und danach /usr/src/$PROGNAME bzw.
|
|||
|
$MAKEPATH/$PROGNAME sowie $TMPROOT gel<65>scht,
|
|||
|
Der Prozess des Archiv Erzeugens kann unterbunden werden, indem die Variable
|
|||
|
MKPKG den Wert <>0 enth<74>lt.
|
|||
|
|
|||
|
So kann also per premk eine Vorbereitung f<>r die mk funktion gemacht werden
|
|||
|
(Anlegen von Verzeichnissen in $TMPROOT, Patches einspielen usw).
|
|||
|
|
|||
|
relativ kurz nach der erstellung von glibc wird die cvs package <20>bersetzt.
|
|||
|
Diese wird im weiteren Verlauf verwendet um zus<75>tzliche Scripten (z.B. start/
|
|||
|
stop Scripten f<>r packages oder tmp/postinstall) vom cvsserver
|
|||
|
:pserver:cvs@cvs.tramp-bbs.de:/pub/CVS
|
|||
|
zu holen - das daf<61>r notwendige Passwort wird gleich zum Start von makeViitor
|
|||
|
abgefragt - es lautet "cvs"
|
|||
|
Damit dies funktionieren kann kopiert makeViitor die Dateien /etc/resolv.conf
|
|||
|
und /etc/nsswitch.conf in das Statische System. Wichtig ist hierbei, das der
|
|||
|
Rechner, auf welchem der Make l<>uft eine Verbindung mit dem Internen, sowie
|
|||
|
eine sauber NameServer Konfiguration haben mu<6D>!
|
|||
|
|
|||
|
Nachdem Viitor Linux erzeugt wurde, besteht sicherlich der Wunsch Dieses System
|
|||
|
Installationsf<EFBFBD>hig auf CD zu brennen. Nun daf<61>r gibt es ebenfalls Hilfen.
|
|||
|
|
|||
|
in DISTTARGET wurde beim Erstellen des Grundsystems ein Verzeichniss genCD mit
|
|||
|
einigen Scripten erzeugt. das genCD script erzeugt 4 CD ISO Images, das GenDVD
|
|||
|
ein DVD ISO Image, von welchen (1. CD Image oder DVD Image) gebootet werden kann,
|
|||
|
und die Installation des Viitor System angestossen werden kann.
|
|||
|
Befor die generierung der Images angestossen werden kann, muss jedoch noch ein passender
|
|||
|
boot Kernel erstellt werden. Hierzu einfach die entsprechenden Menuepunkte des
|
|||
|
genCD/genDVD Scriptes anwaehlen, und den anweisungen folgen.
|
|||
|
|
|||
|
Das Erstellen von Archiven
|
|||
|
|
|||
|
Nun was ist alles zu beachten wenn ein Archiv fuer Viitor Linux gebaut wird.
|
|||
|
Das Archiv soll mit installpkg installiert werden koennen. Dazu ist es
|
|||
|
notwendig etwas ueber die Funktionsweise von installpkg zu wissen.
|
|||
|
Grundsaetzlich erwartet installpkg, dass das Archiv in einem tar.bz2 format
|
|||
|
vorliegt, jedoch mit der Endung *.tbz - analog zu *.tgz.
|
|||
|
installpkg wechselt nach / und entpackt dort das angegebene Archiv. Nach
|
|||
|
dem Enpacken wird geschaut ob die Datei /tmp/postinstall vorhanden ist.
|
|||
|
Ist dies der Fall, so wird /tmp/postinstall ausgefuehrt. Hier bietet sich
|
|||
|
also eine Moeglichkeit initialisierungen nach der Installation durchzufuehren.
|
|||
|
|
|||
|
Dies ist der Einfachste Fall der Packet installation. Zusaetzlich bietet
|
|||
|
ViitorLinux die Moeglichkeit eine sogenannte unattendet Installation zu machen.
|
|||
|
Diese Basiert darauf, das die Konfig eines Rechner komplett gesichert wurde.
|
|||
|
Wird dem installation Script diese Konfiguration mitgegeben, so legt das Script
|
|||
|
die Datei /tmp/NOQUEST an. Danach werden saemtliche Packete mit installpkg
|
|||
|
in das neue System eingespielt.
|
|||
|
Nach diese Installation schaut das Install Script nach, ob fuer installierte
|
|||
|
Packete ein cfg-module vorhanden ist. Wenn dies der Fall ist, wird das
|
|||
|
cfg-module mit der Option r (Recover) gestartet. Dieses muss nun die gesicherte
|
|||
|
Konfiguration fuer diese Package zurueckspielen.
|
|||
|
Daraus ergeben sich einige wichtige dinge fuer das /tmp/postinstall script:
|
|||
|
Sobald die Datei /tmp/NOQUEST existiert DARF das postinstall Script KEINE
|
|||
|
Abfragen an den User stellen. Diese wuerden die Installation stoppen, und
|
|||
|
damit eine beaufsichtigung der installation notwendig machen - genau dieses
|
|||
|
soll aber durch die unattendet installation verhindert werden.
|
|||
|
Weiterhin muss zu jedem packet im CVS Project ViitorInstall ein cfg-module
|
|||
|
erstellt werden.
|
|||
|
|
|||
|
Die CFG-Module
|
|||
|
Die cfg Module sind einfache Scripten, die entweder vom Script Make_Config oder
|
|||
|
von Install_System aufgerufen werden. Ersteres sichert die Konfiguration der
|
|||
|
installierten Packete eines ViitorLinux Systems. Dazu wird fuer jedes Packet
|
|||
|
das entsprechende cfg-module mit der Option b (Backup) aufgerufen.
|
|||
|
Install_System verwendet die gleiche methodik, ruft die Scripte jedoch mit der
|
|||
|
Option r (Recover) auf.
|