SDB:KIWI Kochbuch Live-USB-Stick
| Getestet mit openSUSE | Empfohlene Artikel | Verwandte Artikel | |||
|
|
|
|
||
Inhaltsverzeichnis
- 1 USB-Stick einrichten - unser viertes Rezept
USB-Stick einrichten - unser viertes Rezept
Dieses Beispiel zeigt, wie Sie mit KIWI ein System-Abbild erstellen können, das auf einem USB-Stick installiert werden kann. Dieser USB-Stick erlaubt es Ihnen, das darauf enthaltene Betriebssystem zu starten, so als wäre es auf dem PC installiert. Die Verwendung des Systems auf dem USB-Stick wird Ihr installiertes Betriebssystem nicht beeinflussen.
Um das Betriebssystem auf dem USB-Stick nutzen zu können, muss Ihr Computer von einem USB-Stick starten können. Das wird vom BIOS kontrolliert. Fast alle modernen BIOS-Implementierungen unterstützen die Eigenschaft, vom USB-Stick zu booten. Sollte Ihr System nicht vom USB-Stick starten, besteht die Möglichkeit, die BOOT-Reihenfolge einzurichten. Schauen Sie auf Ihrer Festplatte nach einem MBR (Master Boot Record). Der MBR muss vorher nach einem USB-Gerät suchen.
Ist das Betriebssystem auf dem USB-Stick installiert, dient der Stick als Betriebssystem-Festplatte und Daten werden auf den Stick geschrieben und vom Stick gelesen.
Innerhalb dieses Beispiels schauen wir einige weitere Eigenschaften von KIWI an
- Die Nutzung der YaST2-Firstboot Eigenschaft
- Löschen Sie Pakete, die Sie weder wollen noch brauchen, um Speicherplatz zu sparen
- Hinzufügen von Benutzer und Gruppen
- Mehr Einstellungselemente
- Zusätzliche Werte für das Element Pakete
- Die config.sh Datei
- Das Overlay-Konzept
Nutzung der YaST2-Erststart-Funktion
Die YaST-Erststart-Funktion ermöglicht es Ihnen, das System so zu konfigurieren, dass es als Teil des ersten Starts (initial boot) hoch fährt. Der Anwender wird durch eine Serie von Schritten geleitet, der den regulären Start widerspiegelt. Die Erststart-Funktion ist für Abbild-Einsätze geeignet, wo die Systeminstallation abgeschlossen ist, ergänzt einige abschließende Konfigurationsschritte, wie Root-Passwort, Benutzeranmeldung oder Netzwerk Einrichtung.
Der Standardablauf für die Schnittstelle ist wie folgt:
1. Der Willkommen-Bildschirm 2. Die Lizenzvereinbarung(en) 3. Datum & Zeit 4. Netzwerk 5. Root-Password 6. Benutzerkonto 7. Hardware 8. Abschluss
Die Nutzung der Erststart-Funktion erfordert es, dass das yast2-firstboot-Paket installiert ist. Das yast2-Erststart-Paket ist nicht Teil eines Software-Musters (Pattern) oder von Abhängigkeitsketten. Aber, das Paket muss zum Abbild durch Verwendung des <package>-Elements in der config.xml-Datei hinzugefügt werden, wie unten gezeigt wird:
<package name="yast2-firstboot"/>
Der Erststartablauf wird von der Datei firstboot.xml kontrolliert. Diese Datei ist eine Teil der Datei YaST-control.xml. Sie wird verwendet, um die komplette SUSE-Installation zu steuern. Die Steuer-Datei firstboot.xml wird mit dem Yast2-Erststart-Paket installiert und kann im Verzeichnis /etc/YaST2 des installierten Systems gefunden werden. Innerhalb der Steuer-Datei werden der Ablauf und vorgeschlagene Konfigurationen verwendet, um Konfigurationsschritte während des initialen Starts des Systems hinzuzufügen oder zu löschen. Durch die Modifizierung der Datei kann man die Erststart-Prozedur einrichten, um die Installationsanforderungen des startenden Systems abzugleichen. Zusätzlich zu den gelieferten Erstboot-Komponenten können spezielle Bildschirme hinzugefügt werden. Sie liefern Flexibilität während der Nach-Installations-Konfiguration.
Für ergänzende Details über den Erststart verweisen wir auf die YaST2 Firstboot Dokumentation. Wenn Sie das Paket auf Ihrem Rechner installiert haben, haben Sie Zugang zur Dokumentation unter /usr/share/doc/packages/yast2-firstboot/index.html.
Die Durchführung der Erststart-Prozedur für das KIWI-Abbild ist ein geradliniger Prozess. Fügen Sie das yast2-firstboot-Paket zu config.xml hinzu, wie oben gezeigt, und platzieren die Datei config-yast-firstboot.xml an die oberste Stelle des Konfigurationsverzeichnisses, so dass config.xml und config-yast-firstboot.xml auf der gleichen Ebene des Konfigurationsverzeichnisses angeordnet sind. Sie können die Datei config-yast-firstboot.xml an Ihre Bedürfnisse anpassen und KIWI wird die Details handhaben.
Ein guter Startpunkt für die Konfigurationsdatei zum Erststart ist die Verwendung der Konfigurationsdatei firstboot.xml. Installieren Sie das Paket yast2-firstboot auf Ihr System und kopieren Sie die Datei in Ihr Konfigurationsverzeichnis.
Hinweis: Die Installation des Paketes yast2-firstboot auf Ihrem System wird nicht den Erststartprozess verändern, wenn Sie das nächste Mal Ihr System neu starten.
Wenn die Datei config-yast-firstboot.xml in Ihrem Konfigurationsverzeichnis vorhanden ist, wird KIWI die Datei verarbeiten und Ihr Abbild einrichten:
- 1. die Erststartfunktion ermöglichen
- 2. YaST im Erststartmodus starten, wenn das Abbild gebootet wird
Die Firstboot-Prozedur wird dann den Schritten folgen, die in der Datei config-yast-firstboot.xml eingerichtet wurden. Wenn der Erststart-Prozess erfolgreich eingerichtet ist, dann ist die Umgebung so verändert, dass die Erststartprozedur während eines anschließenden Starts des Systems nicht ausgeführt wird.
Der Erststartprozess bietet eine zusätzliche Funktion zur Anpassung an. Es ist möglich, am Ende der Erststart-Konfiguration Scripte auszuführen. Legen Sie Ihre Scripte im Verzeichnis /usr/share/firstboot/scripts ab und sie werden nach nach den init-Scripten ausgeführt.
Zum Beispiel, wenn Sie ein Shellscript, myscript.sh genannt, haben, dass am Ende der Erststart-Prozedur ausgeführt werden soll, dann kopieren Sie das Script in das Verzeichnis <MY_CONFIG_DIR>/root/usr/share/firstboot/scripts.
cp myscript.sh <MY_CONFIG_DIR>/root/usr/share/firstboot/scripts
Das Script muss ausgeführt werden. Die Funktion funktioniert für jede ausführbare Datei. So können Sie auch kompilierte Binärdateien in <MY_CONFIG_DIR>/root/usr/share/firstboot/scripts einfügen, damit sie gestartet werden, wenn das System anfänglich startet.
Pakete löschen, die man nicht braucht/möchte
Das verpflichtende <packages>-Element spezifiziert eine Liste von Paket- und/oder Muster-Namen. Das type-Attribut des Elements bestimmt, wie die benannten Pakete oder Muster verwendet werden. In den vorhergehenden Beispielen konzentrierten wir uns auf das Listenelement der Pakete vom Typ image. Die Angabe des Typs image zeigt, dass alle Pakete oder Muster, die in der Paketliste von diesem Typ aufgeführt sind, Teil des Systems sein werden, das erstellt wird.
<packages type="image"> ... </packages>
Wir trafen vorher auch den Typ bootstrap. Pakete und Muster, die in der Paketliste vom Typ bootstrap benannt sind, werden extern zum Abbild hinzugefügt und verwendet, um das neue Root-System , das mit KIWI erstellt wird, zu aktivieren (bootstrapping). Das externe System braucht nur ausreichend Software, um das Root-Verzeichnis in das neue System zu verändern (chroot). Deshalb sind glibc und filesystem als Einträge in die Liste ausreichend.
<packages type="bootstrap"> ... </packages>
Das Problem mit dem ständigen Hinzufügen von Paketen und Strukturen/Mustern (patterns) ist, dass unser Abbild immer größer wird. Ebenso ist es unvermeidlich, dass einige Pakete, die einbezogen wurden, ungewollt sind oder nicht benötigt werden. Darum ist das Löschen von Paketen ebenso wichtig wie das Hinzufügen. Die Verwendung des Wertes delate für das Typ-Attribut des <package>-Elements erlaubt es Ihnen, Pakete aus Ihrem Abbild zu löschen.
<packages type="delete"> ... </packages>
Wenn Sie mit Strukturen/Mustern (patterns) arbeiten, ist es gut möglich, dass Sie Pakete besitzen, die Sie in Ihrem Abbild nicht benötigen oder wollen. Zum Beispiel beinhaltet die kde4-Struktur eine große Paketanzahl. Manche Pakete mögen nicht für das von Ihnen zu konfigurierende Abbild geeignet sein.
Eine Möglichkeit besteht darin, dass Sie alle Pakete, die Sie benötigen oder wollen, zur Liste <packages type="image"> hinzufügen, anstelle von Mustern. Dieser Weg könnte zu einer Menge Schreibarbeit und zur Untersuchung der Paketbezeichnungen und ihrer Verknüpfung zu den Mustern (pattern) führen. Die zweite Möglichkeit ist es die Muster zu verwenden und die Pakete zu löschen, die für Sie nicht von Interesse sind.
In diesem Beispiel nutzen wir die Muster base und kde4. Aber wir würden gern OpenOffice, Firefox und einige andere Pakete vom Abbild ausschließen, um die Abbildgröße zu reduzieren. Die folgende Beschreibung in der Datei config.xml erlaubt es uns die Pakete zu löschen.
<packages type="delete">
<package name="MozillaFirefox"/>
<package name="OpenOffice_org-branding-openSUSE"/>
<package name="OpenOffice_org-templates-labels-a4"/>
<package name="OpenOffice_org-calc"/>
...
</packages>
Das Element <packages> unterstützt zwei zusätzliche Werte für das Attribut type. Das sind xen und vmware. Mit diesen Attribut-Werten kann man Pakete spezifizieren, die nur einbezogen werden, wenn ein Xen- oder VMware-Abbild erzeugt wird. Die Pakete in diesem Abschnitt sind zusätzlich zu den Paketen enthalten, die für den Typ image passend aufgelistet sind.
Benutzer und Gruppen hinzufügen
Das optionale Element <users> beschreibt eine Liste von Benutzern, die zum Abbild hinzugefügt werden sollen. Das verpflichtende Attribut group des <users>-Elements spezifiziert die Gruppe, zu der die Liste der Benutzer gehört. Wenn die spezifizierte Gruppe nicht existiert, dann wird sie erstellt. Die Benutzerliste darf nicht leer sein, sondern muss mindestens einen Eintrag vom Typ <user> enthalten. Das <user>-Element besitzt die Attribute name, pwd und home, um den Benutzer, das verschlüsselte Passwort und den Pfad zum Home-Verzeichnis des Benutzers festzulegen.
Das verschlüsselte Passwort kann von KIWI mit dem Werkzeug −−createpassword erzeugt und anschließend das Ergebnis ausgeschnitten und in die Datei config.xml eingefügt werden.
<users group="users">
<user pwd="$1$wYJUgpM5$RXMMeASDc035eX.NbYWFl0" home="/home/tux" name="tux"/>
</users>
<users group="root">
<user pwd="$1$wYJUgpM5$RXMMeASDc035eX.NbYWFl0" home="/root" name="root"/>
</users>
In diesem Beispiel erstellen wir einen Benutzer namens tux in der Gruppe users und einen Benutzer root in der gruppe root. Beide haben das gleiche Passwort.
Es ist ebenso möglich, eine Benutzer-ID oder eine Gruppen-ID hinzu zu fügen, wenn man das optionale Attribut id der Elemente <users> oder <user> verwendet, wie unten gezeigt wird.
<users group="users" id="[the-id-as-number]"> <user pwd=... home=... name=... id="[the-id-as-number]"> ... </users>
Ein zweiter Blick auf die bevorzugten Einstellungen
Das verpflichtende Element <preferences> ist ein Listenelement, das Informationen über den gewünschten Abbildtyp, den Paket-Manager, die Version dieses Abbildes und andere optionale Vorzugselemente.
Vorher haben wir das <type>-Element beschrieben, das verwendet wird, um den Abbild-Typ, der mit KIWI erstellt werden soll, zu steuern. Zusätzlich zum Typ-Element könnte die Preferenzen-Liste eine Anzahl anderer Elemente enthalten. Einige von ihnen werden unten detaillierter beschrieben. Unten ist die Liste der Vorlieben unseres aktuellen Beispiels.
<preferences>
<type filesystem="squashfs" boot="usbboot/suse-11.1">usb</type>
<type filesystem="squashfs" boot="oemboot/suse-11.1">oem</type>
<type filesystem="squashfs" boot="vmxboot/suse-11.1">vmx</type>
<version>1.1.2</version>
<packagemanager>zypper</packagemanager>
<rpm-check-signatures>false</rpm-check-signatures>
<rpm-force>true</rpm-force>
<rpm-excludedocs>true</rpm-excludedocs>
<oem-swap>false</oem-swap>
<oem-kiwi-initrd>true</oem-kiwi-initrd>
<oem-boot-title>USB</oem-boot-title>
<locale>en_US.UTF-8</locale>
<keytable>us.map.gz</keytable>
<timezone>US/Eastern</timezone>
</preferences>
Starten wir mit dem Typ-Element, das in vorangegangenen Beispielen bereits angetroffen haben. Es ist zu bemerken, dass wir 3 verschiedene Abbild-Typen mit dieser Beschreibung bauen können, USB, OEM und VMX. Keines der spezifizierten Typen ist als primär gekennzeichnet. Darum muss bei Verwendung dieser Beschreibung der gewünschte Abbild-Typ auf der Kommandozeile angegeben werden.
- Typ USB
- Verwenden Sie diesen Typ, um ein System für den USB-Stick zu erstellen, mit dem Dateisystem-Attribut boot=”usbboot/suse-*”
- Typ OEM
- Verwenden Sie diesen Typ, um ein vorinstalliertes Festplattensystem zu erstellen, mit dem Dateisystem-Attribute, boot=”oemboot/suse-*”
- Mit dem optionalen Format-Attribut, gesetzt auf ”iso” oder ”usb” wird KIWI zusätzlich ein Installations-Abbild erzeugen, das für eine CD/DVD oder einen USB-Stick geeignet ist.
- Das OEM-Abbild wird das Pre-load-System auf den Speichergeräten des Systems zum Einsatz bringen, von dem das Installationsmedium gestartet wird. Das Speichergerät wird während der Startzeit entdeckt.
- Typ VMX
- Verwenden Sie diesen Typ, um ein virtuelles Plattensystem zu erstellen mit dem Dateisystem-Attribut boot=”vmxboot/suse-*” und dem optionalen Format-Attribut.
- Das Format-Attribut spezifiziert eines der von QEMU unterstützten Virtualisierungsformate, z. B. vmdk oder qcow2.
- Das optionale Attribut vga kann spezifiziert werden, um das Kernel-Framebuffer-Modus zu konfigurieren. Detaillierte Informationen über die möglichen Werte können in /usr/src/linux/Documentation/fb/vesafb.txt gefunden werden.
- Das Attribut vga funktioniert ebenfalls für die Abbild-Typen USB und OEM.
- Zusätzliche Typen
- Zusätzlich zu den oben aufgeführten Typen unterstützt KIWI Typen von ISO, XEN, PXE und EC2.
- Typ USB
Für detaillierte Informationen verweisen wir auf KIWI Image System Cookbook.
In diesem Beispiel ist das Dateisystem-Attribut auf squashfs gesetzt. Sie können jedes Dateisystem verwenden, das von Linux als Boot-Partition unterstützt wird. Einige spezielle Charaktermerkmale des komprimierten squashfs Dateisystems sind unten aufgelistet.
- filesystem="squashfs"
- Das wird das Abbild, das das squashfs Dateisystem verwendet, komprimieren.
- Der Boot-Prozess wird automatisch das Dateisystem aufs als ein Overlay-Dateisystem verwenden, um den kompletten Baum im Lese-Schreib-Modus einzubinden (zu mounten).
- KIWI erzeugt eine zusätzliche ext2-Partition auf dem USB-Stick, um den Schreibmodus zu unterstützen. Um die Kompression mit squashfs zu unterstützen, ist es erforderlich, dass das squashfs-Paket auf dem System installiert ist, das verwendet wird, um das Abbild zu erstellen. Diese Forderung gilt auch für aufs.
- filesystem="squashfs"
Nun werden wir einen Blick auf andere Einträge im Listen-Element Vorlieben (preferences) werfen.
Der OEM-Typ und OEM-Vorzugseinstellungen
Standardmäßig wird der OEM-Boot-Prozess je eine Partition swap, /home und / (root) erzeugen oder modifizieren. KIWI unterstützt OEM-spezifische Elemente, um das Verhalten für den OEM-Boot-Prozess anzupassen.
- <oem-swap>true|false</oem-swap>
- Angeben wenn eine swap-Partition erzeugt werden sollte.
- <oem-swap>true|false</oem-swap>
- <oem-kiwi-initrd>true|false</oem-kiwi-initrd>
- Wenn dieses Element auf true gesetzt ist, wird das Anfangs-OEM-Boot-Abbild (initrd) nicht durch das vom System (mkinitrd) erzeugte initrd ersetzt.
- Diese Option macht Sinn, wenn das Zielspeichergerät für das Abbild keine Festplatte sondern zum Beispiel ein USB-Stick ist. In diesem Fall könnte es erforderlich sein, den Speicherort auf der First-Boot neu zu erkennen, was als Teil des OEM-Boot-Abbildes durchgeführt wird.
- <oem-kiwi-initrd>true|false</oem-kiwi-initrd>
- <oem-boot-title>text</oem-boot-title>
- Standardmäßig wird die Zeichenkette OEM an das Boot-Manager-Menü angehängt, wenn KIWI die GRUB-Konfiguration während des ersten Einsatzes erzeugt. Der Wert von oem-boot-title erlaubt es, einen benutzerdefinierten Namen einzusetzen, der anstelle von OEM verwendet wird.
- <oem-boot-title>text</oem-boot-title>
KIWI unterstützt zusätzliche OEM-spezifische Optionselemente. Detaillierte Informationen finden Sie unter KIWI Image System Cookbook.
Einige spezifische Elemente des Paket-Managements (rpm)
- rpm-check-signatures
- Gibt an, ob RPM die Paket-Signatur prüfen sollte oder nicht
- rpm-check-signatures
- rpm-force
- Gibt an, ob RPM mit –force aufgerufen werden sollte.
- rpm-force
- rpm-excludedocs
- Gibt an, ob RPM die Installation der Paket-Dokumentation überspringen sollte.
- rpm-excludedocs
Lokalisierungs-Elemente
- keytable
- Gibt den Namen der Liste der zu verwendenden Tastaturbelegung an. Der Wert entspricht einer Datei unter /usr/share/kbd/keymaps wie us.map.gz, de.map.gz oder dvorak.map.gz. Die KEYTABLE-Variable wird in einer Datei unter /etc/sysconfig/keyboard gemäß der Länder spezifischen Tastaturbelegung gesetzt.
- keytable
- timezone
- Gibt die Zeitzone an. Die verfügbaren Zeitzonen sind im Verzeichnis /usr/share/zoneinfo zu finden. Geben Sie den Attributwert gemäß /usr/share/zoneinfo an.
- Zum Beispiel, der Wert Europe/Berlin für /usr/share/zoneinfo/Europe/Berlin. KIWI verwendet diesen Wert, um die Zeitzone in /etc/localtime für das Abbild zu konfigurieren.
- timezone
- locale
- Gibt den Namen der zu verwendenden Gegend an, was den Inhalt der RC_LANG System-Umgebungs-Variablen in /etc/sysconfig/language definiert. Der Wert korrespondiert zu den Einträgen unter /usr/share/X11/locale, wie etwa en_US.UTF-8 oder ja_JP.UTF-8.
- locale
Attribute des Elements packages
Das Paket-Listen-Element enthält die Liste der Pakete und Pattern, die verwendet werden, um das Abbild zu bauen. Patterns sind SUSE-spezifisch und verfügbar seit openSUSE 10.1. Ein Pattern wird durch einen Namen identifiziert, wie gnome oder kde, und identifiziert eine Anzahl von Paketen, die mit diesem benannten Pattern verbunden sind. Die Verwendung von Pattern reduziert die Anzahl der Pakete die ausdrücklich aufgelistet werden müssen.
Standardmäßig werden nur die geforderten Pattern und Pakete automatisch in das Abbild einbezogen.
<packages type="image" patternType="plusRecommended">
<packages type="image" patternPackageType="plusRecommended">
Mögliche Werte für patternType und patternPackageType sind
- plusRecommended
- Nimmt Pattern und Pakete auf, durch das gegebene Pattern gefordert und empfohlen werden.
- plusRecommended
- plusSuggested
- Nimmt Pattern und Pakete auf, durch das gegebene Pattern gefordert und vorgeschlagen werden.
- plusSuggested
- onlyRequired
- Nimmt nur Pattern und Pakete auf, durch das gegebene Pattern gefordert werden- das ist der Standard.
- onlyRequired
Die spezifizierte Liste von Paketen (alle Pakete, die namentlich aufgeführt sind, und Pakete, die durch einen Pattern-Namen einbezogen werden) wird verwendet, um eine Paketliste zu erzeugen, die installiert werden sollen. Die erzeugte Liste ist das Ergebnis der Auflösung der Abhängigkeiten für alle spezifizierten Pakete. Das kann dazu führen, dass die Einbeziehung eines vorgeschlagenen Paketes zusätzliche Pakete erfordert und empfiehlt.
Zusätzliche Informationen können unter KIWI Image System Cookbook gefunden werden.
Die Datei config.sh
Am Ende des Vorbereitungsschritts (kiwi -p) wird das Script config.sh ausgeführt, wenn es an der obersten Stelle des Konfigurationsverzeichnisses vorhanden ist. Es ist vorgesehen, das Script für Konfigurationsaufgaben des Betriebssystems auf dem Gerät zu verwenden.
Konfigurationsaufgaben sind Schritte, wie die folgenden
- Aktivierung von Services
- Erstellung von Konfigurationsdateien
- Vorbereitung einer Umgebung für einen Erststart-Arbeits-Ablauf
- u.s.w.
Wenn die Datei config.sh mit einem Exit-Code != 0 existiert, wird KIWI den Vorbereitungsschritt mit einem Fehler abbrechen.
Es wird heftig abgeraten, die Datei config.sh als ein Mittel zur "manuellen" Löschung von Paketen oder Paketteilen zu verwenden. Das könnte einen negativen Einfluss auf die Fehlerfreiheit des Abbildes haben und Instabilitäten verursachen.
Um zusätzliche Software zu managen, wird empfohlen, das Script image.sh zu verwenden. Das Script image.sh wird aufgerufen, wenn auf der obersten Ebene des Konfigurationsverzeichnisses am Beginn des Erzeugungsschritts (kiwi -c) vorhanden ist.
Im Gegensatz zu dem Script config.sh ist der Zweck des Scripts install.sh weniger definiert. Es wurde als ein Haken geschaffen, um mit dem Abbild, das als außerhalb der Grenzen erzeugt wird, die als Abbild-Konfiguration betrachtet werden, zu arbeiten. Das Script install.sh wird gewöhnlich verwendet, um Pakete zu löschen, die im Abbild über Abhängigkeiten enthalten sind, aber nicht für die spätere Verwendung des Betriebssystems benötigt werden.
Innerhalb der Scripte config.sh und image.sh sind eine Reihe von Funktionen verfügbar, um gewöhnliche Aufgaben durchzuführen. Eine detaillierte Beschreibung dieser Funktionen finden Sie in den Anleitung-Seiten kiwi::config.sh oder kiwi::images.sh
oder
Das Overlay Konzept
In den vorangegangenen Beispielen werden Sie ein Verzeichnis namens root auf der oberen Ebene des Konfiguration-Verzeichnisses bemerkt und sich über seinen Zweck gewundert haben. Das root-Verzeichnis in der Abbild-Beschreibung repräsentiert einen Eintrag-Punkt zum Wurzelverzeichnis (/) des zu bauenden Abbildes. Jede Datei oder jedes Verzeichnis, das innerhalb des Root-Verzeichnisses existiert, wird in das Wurzelverzeichnis des ungepackten Abbildes kopiert, nachdem alle Pakete installiert wurden.
Mit dem Wurzel-Verzeichnis-Overlay-Konzept steht Sie eine sehr hilfreiche Anpassungs-Methode zur Verfügung. Es ist sehr leicht, die spezifischen Konfigurationseinstellungen auf das Abbild anzuwenden, indem Sie einfach die Konfigurationsdatei an die richtige Stelle innerhalb des Wurzelverzeichnisses setzen.
In diesem Beispiel wird der Overlay-Mechanismus für die folgende Konfiguration genutzt:
./root
`-- etc
|-- X11
| `-- xorg.conf <== die X Konfiguration
|-- init.d
| |-- earlyxdm <== erforderliches Start-Skript für X
| |-- sax <== X Konfigurationsprogramm
| `-- xdm <== Start-Skript für Anzeigemanager
|-- inittab
`-- sysconfig
|-- displaymanager <= Einstellungen für den Anzeigemanager gestartet mit Hilfe von xdm
|-- network
| `-- ifcfg-eth0 <= eine Standard-Datei zur Netzwerkkonfiguration
`-- windowmanager <= Einstellungen für den Fenster-Manager
Die Kommandos, um unser Beispiel zu bauen
Mit diesem haben wir das ungepackte Abbild in /tmp/myusb/image_root erstellt. Aus unseren früheren Erklärungen über die Konfiguration-Datei wissen wir, das wir zwei unterschiedliche Abbilder aus unserem Baum in image_root bauen können.
- Der "USB" Abbild-Typ
- erstellt alle geforderten Dateien zum starten des Betriebssystems aber benötigt die Verwendung von KIWI, um das Abbild auf dem USB-Stick aufzusetzen.
- Der "OEM" Abbild-Typ
- erlaubt es Ihnen, eine virtuelle Festplatte zu bauen, die eine virtuelle Festplattengeometrie einschließlich aller Partitionen und Startinformationen in einer Datei repräsentiert. Sie können diese Datei auf dem USB-Stick zum Einsatz bringen mit Hilfe des dd-Kommandos. Beim Erststart wird die virtuelle Festplattengeometrie an die reale Festplattengeometrie auf dem USB-Stick angepasst.
Typ USB
- Erzeuge das Abbild
- Schließe den Stick an
- Setze das Abbild ein
Typ OEM
- Erzeuge das Abbild
- Schließe den Stick an
- Bestimme den Gerätepfad
- Setze das Abbild ein
dd if=/tmp/myusb/image/suse-11.1-live-stick.i686-1.1.2.raw of=</dev/yourdev> bs=32
Sie können den USB-Stick testen, indem Sie eine Maschine verwenden, die vom USB-Stick booten kann, oder eine virtuelle Maschine Ihrer Wahl einsetzen. Wenn Sie den Stick auf einer VM testen, seien Sie darauf aufmerksam gemacht, dass der USB-Stick für die VM wie eine normale Festplatte aussieht. Das ist wichtig, da der KIWI-Boot-Prozess nach dem USB-Stick sucht, um das richtige Speichergerät einzuhängen. In einer virtuellen Umgebung erscheint der USB-Stick als eine Festplatte und nicht als ein USB-Stick. Wenn Ihre Virtualisierungslösung kein virtuelles BIOS anbietet, das das Booten vom USB-Stick unterstützt, sollten Sie den Stick auf einer realen Hardware testen.
Login Details
* User root pwd: linux * User tux pwd: linux