Linupedia.org - Benutzerbeiträge [de]

Backup

2014-07-18T13:55:04Z

Josef-wien:

* [[Backupprogramme]] - Bekannte und gute Backupprogramme unter Linux - empfohlen von Linux-Club Mitgliedern
* [[Backupkonzept]] - Eine sehr detaillierte Beschreibung wie man einen Server sichern und recovern kann (mit tar)
* [[System- und Datensicherung einrichten]] - Vorstellung der Tools mkcdrec welches CD Images eines Systems erstellt. Zum restore ist einfach von der ersten CD zu booten.
* [[PartImage]] - Die gesamte Partition mit dem Dateisystem als Image sichern.
* [[Rsync]] - Sehr detaillierte Beschreibung des mächtigen rsync
* [[Backup Script]] - Script zur Archivierung
* [[Home Laufwerk sichern]] - Script zum Sichern des Home Laufwerks auf einen Server (mit rsync über ssh)
* [[Backupkonzept der Linux-Club Mitglieder]] - Welche Strategie wenden die LC Mitglieder an um ihr System zu sichern

----

[[Hauptseite|zurück zur Hauptseite]]

[[Category:Backup]][[Kategorie:Übersicht]]

Zwei Kernel parallel installieren

2014-06-23T20:18:23Z

Josef-wien: 13.1 und Verweis auf GRUB 2-Artikel ergänzt.

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1, 11.3, 11.4, 12.1, 12.3, 13.1
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten [[Kernel]] rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln. D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

Mit Ausnahme von openSUSE 11.1 besteht der kompilierte Kernel aus einer *.rpm-Datei. Bei openSUSE 11.1 sind es mit Ausnahme des Vanilla-Kernel drei *.rpm-Dateien (kernel-xxx, kernel-xxx-base und kernel-xxx-extra, xxx steht für den Kernel-Typ, z.B. default), die als Einheit betrachtet werden sollen; die Datei kernel-xxx-extra sollte nur dann weggelassen werden, wenn man ganz sicher ist, diese Module nicht zu benötigen. Ab openSUSE 11.2 ist das Paket kernel-xxx-base nur eine relativ kleine Teilmenge von kernel-xxx und für den normalen Anwender nicht zielführend.

== Bevorzugte Variante ==

Seit einigen openSUSE-Versionen ist es möglich, mit [[zypper]] (und damit auch mit YaST) mehrere Kernel desselben Typs zu installieren. Dazu muss in der Datei /etc/zypp/zypp.conf die Zeile
multiversion = provides:multiversion(kernel)
aktiviert werden.

Ab openSUSE 12.3 ist diese Einstellung standardmäßig aktiviert, die Anzahl der gleichzeitig installierten Kernel wird durch die Angabe
multiversion.kernels = ...
festgelegt, die möglichen Werte sind in der Datei /etc/zypp/zypp.conf angeführt.

== Früher notwendige Varianten ==

=== Erste Variante ===

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

=== Zweite Variante ===

Dazu wird zunächst der aktuelle Kernel aus der [[RPM]]-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit [[apt]] oder [[YaST]] oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

Unter openSUSE 11.1 ist diese Variante aufgrund von Abhängigkeitsproblem leider nicht mehr möglich.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Ab openSUSE 11.1 (und möglicherweise früher) genügt es jetzt im Normalfall zu überprüfen, ob der Kernel in <code>/boot/grub/menu.lst</code> richtig eingetragen wurde. Nur bei älteren Versionen ist es wichtig zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>. Neuere openSUSE-Versionen schreiben nämlich nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>. Bei Bedarf muss darum zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im [[GRUB]]-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Hinsichtlich GRUB 2 sei auf den Artikel [[GRUB_2]] verwiesen.

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]] [[Category:Bootmanager]]

Mit dem /home auf neue Partition "umziehen"

2014-06-20T22:30:21Z

Josef-wien: Tippfehler korrigiert

So solltet ihr vorgehen:
(alle weiteren Punkte setzen voraus, dass man root Rechte hat)

1) eine freie Partition erstellen und formatieren

2) diese nach z.B. /mnt/neu mounten

3) die Daten des "alten" home-Verzeichnisses nach /mnt/neu kopieren, wobei die aktuellen jeweiligen Dateiattribute beibehalten werden sollten (insbesondere die Rechte)

4) Verwendung des neuen /home vorbereiten: 
4.1) falls /home bisher auch eine eigene Partition war: in der /etc/fstab die neue Partition für /home eintragen und die alte home-Partition z.B. für /mnt/neu 
4.2) /home war bisher keine eigene Partition: in der /etc/fstab einen neuen Eintrag für die neue Partition anlegen, z.B. für /mnt/neu

5) reboot in single user mode und als root anmelden 
für 4.1) sollte /home nun die neue Partition verwenden und das alte /home unter /mnt/neu erreichbar sein; dann nocheinmal überprüfen, ob in /mnt/neu noch irgendwas
neues hinzugekommen ist, was noch nicht in /home ist 
für 4.2) das neue HOME ist unter /mnt/neu gemountet und es kann geprüft werden, ob in /home noch irgendwas neues hinzu kam, was noch nicht in /mnt/neu ist

6) übergehen in Normalbetrieb :)
für den Fall 4.1) kann nun in den Multiusermode gewechselt werden und bei Bedarf die Daten in /mnt/neu gelöscht werden 
/mnt/neu steht dann als zusätzlicher Speicherplatz zur Verfügung 

für den Fall 4.2) kann nun das ganze Verzeichnis /home gelöscht werden und das neue HOME wird DANACH zu /home verlinkt: ln -s /mnt/neu /home

Zum Kopieren am besten den "tar"-Befehl aus diesem Artikel verwenden:

[[Kopie_der_root_Partition]]

oder mit Hilfe von rsync (dann kann für 3) und 5) der gleiche Befehl verwendet werden):
für 3): rsync -av /home/ /mnt/neu
für 5): Fall 4.1) rsync -av /mnt/neu/ /home

Anmerkung zu Step 3:

Damit man nicht den Überblick verliert, in welcher Version man sich befindet
legt man im alten /home eine Datei an mit
touch /home/alteshome
Das Gleiche im neuen /home mit
touch /mnt/neu/neueshome

Und noch eine Anmerkung:

Es ist '''auch möglich andere Verzeichnisse''' auf eine extra Partition zu packen.
Dafür kann dieses HowTo auch, in angepasster Form, verwendet werden. 
Mögliche Verzeichnisse sind:
'''/usr, /var, /tmp oder auch /opt'''

'''''Beachte'''''

'''Die Verzeichnisse /bin, /dev, /etc, /lib und /sbin
müssen '''zwingend''' auf der Wurzelpartition liegen''', alle anderen Verzeichnisse können theoretisch auf andere Partitionen ausgelagert werden.

Zumindestens das Verzeichnis /root, das Heimatverzeichnis des Systemverwalters sollte (muß aber nicht) noch auf dem Wurzelverzeichnis gelegen sein, da es vorkommen kann, daß der Systemverwalter in einem Wartungsmodus mit dem System arbeiten muß, in dem nur das Wurzelverzeichnis eingehängt ist.

admine /carsten
[[Category:Partitionen]]

Hardware

2014-02-28T16:26:17Z

Josef-wien: Link auf SSD_Optimierungen eingefügt (war bisher nur in Kategorie „Hardware“ enthalten).

'''[[Hardwareinfos /ACPI/APIC/Powermanagement]]'''

Dieses Howto behandelt hardwarenahe Probleme, wie:
* Powermanagement
* Hardwareinformationen auslesen und interpretieren
* Taktung eines Prozessors
* Stromsparfunktionen
* ACPI / APIC und Powermanagement
* Temperaturüberwachung

weiteres:

 


== Tipps zum Hardwarekauf ==
* [[Tipps zum Hardwarekauf]] - Hier finden sich mehrere Artikel mit Hardwaredatenbanken. Die Artikel geben dem Leser beim Kauf neuer Hardware konkrete Hilfestellungen an die Hand und nennen Hardware, die mit Linux zusammenarbeitet.

== Solid-State-Drive (SSD) ==
* [[SSD_Optimierungen]] - Optimierungen beim Einsatz einer SSD

==Soundprobleme==
* [[Allgemeine Soundprobleme]]

=== Intel® ===
* [[High Definition Audio AC'97]]

Probleme bei Einrichtung von ICH6 , ICH7 , ICH8 , ICH9 Sound, Realtek ,wie ALC880 , CMI und andere.

== Chipkartenleser ==
* [[ Moneyplex und Towitoko Chipdrive]] - Probleme bei der Initialisierung des Chipdrive
* [[Kartenleser ReinerSCT cyberJack pinpad/e-com mit Moneyplex]]

== Tastaturen ==
* [[Tastaturlayout]] - Tastaturlayout systemweit einstellen
* [[Cherry Linux-Tastatur]] - Installationsanweisung ohne zusätzliche Software und Bilder der Tastatur
* [[Zusätzlichen Tasten einer Tastatur Funktionen zuweisen]] - Wie man Sondertasten mit linEAK nutzen kann (auch wenn sie von ''xev'' nicht erkannt werden)
* [[LIRC]] - LIRC-Konfiguration unter Linux (derzeit nur SuSE)
* [[Xbindkeys]] - Multimediatasten von Windowstastaturen aktivieren.
* [[Keytouch (Besipiel Logitech S510)]] - Mutlimediatesten bequem mit grafischer Oberfläche konfigurieren.
* [[Logitech diNovo Edge]] - Einrichten einer Bluetoothtastatur im HIDD Modus

== Mäuse ==

* [[Logitech MX1000]] - Alle Tasten der Maus nach Wunsch belegen mit Hilfe von xbindkeys

== NAS-Anbindung an Linux-Systeme ==
Wie bindet man eigentlich '''''N'''''etwork'''''A'''''ttached'''''S'''''torage-Devices (="Netzwerkfestplatten") an einen oder mehrere Linux-Rechner an?
*[[WD NetCenter]]

== Grafiktabletts ==
[[Grafiktabletts]] - Eine Liste unter openSUSE funktionierender Grafiktabletts.

== TV Karten ==

* [[KNC ONE TV STATION DVB-C]]
* [[Pinnacle72e|Pinnacle PCTV 72e USB DVB-T]]
[[Category:Hardware]][[Kategorie:Übersicht]]

GRUB Legacy

2013-12-18T16:46:49Z

Josef-wien: (vorhin das falsche Feld angeklickt)

{{Infobox_Software|
Name= GRUB
|Screenshot=
|Beschreibung= Grub Legacy
|Hersteller= Das GRUB-Team
|AktuelleVersion= 0.97
|AktuelleVersionFreigabeDatum= 5/2006
|Betriebssystem= Unix-Derivate, [[Linux]]
|Kategorie= [[Bootmanager]]
|Lizenz= [[GNU General Public License|GPL]]
|Deutsch= nein
|Website= http://www.gnu.org/software/grub/manual/legacy/index.html
}}

== Was ist GRUB Legacy ==

GRUB (Grand Unified Bootloader) ist ein Boot-Manager, der heutzutage bei vielen Linux-Distributionen, wie z.B. Red Hat, [[Mandrake]] und auch [[openSUSE]] per default installiert wird.
GRUB in seiner heutigen Form wird vom GNU Projekt gepflegt und weiterentwickelt.
Aktuell ist [[GRUB 2]] eine komplette Neuentwicklung aus dem selben Team, aber nicht kompatibel zu Grub Legacy.<ref>http://www.gnu.org/software/grub/manual/legacy/index.html</ref>

GRUB Legacy kann verschiedene UNIX-Derivate wie [[Linux]], FreeBSD, NetBSD oder OpenBSD starten und auch das Booten von Windows ist kein Problem.

== Der [[Bootvorgang]] mit GRUB (Legacy)==

''Der Bootloader GRUB startet in 2 Stufen:''

'''Stage1''' befindet sich entweder im Master Boot Record (MBR) der Festplatte oder im Boot-Sektor einer Partition. Die einzige Aufgabe dieser Stufe ist es, '''Stage2''' zu laden.
Stage2 stellt die eigentlichen Funktionen des Bootloaders bereit. Diese befindet sich unter /boot/grub/stage2.

Bei der Installation wird in der Stufe 1 festgeschrieben, an welchem physikalischen Ort sich die Stufe 2 befindet. Befindet sich /boot/grub in bestimmten Dateisystemen, dann wird eine 3. Stufe zwischen Stage1 und Stage2 benötigt, mit deren Hilfe das Dateisystem und somit die GRUB-Dateien gelesen werden können. Hier lädt stage1 die stage1_5, welche Zusatzcode für den Zugriff auf das verwendete Dateisystem enthält, und diese lädt dann stage2.

Stage2 kann dann den Linux-Kernel laden und booten, oder auch andere Betriebssysteme oder andere Bootloader starten.

== Festplattenbezeichnung unter GRUB ==

Die Besonderheit von GRUB ist die Bezeichnung der Festplatten und Partitionen.
Sie unterscheidet sich von der gewohnten Linux-Bezeichnug der Devices.

hd0 = erste Festplatte
hd1 = zweite Festlatte ...

hd0,0 = 1. Partition der ersten Festplatte
hd1,2 = 3. Partition der zweiten Festplatte ...

Für UFS oder UFS2 benutzende Systeme wie Solaris oder BSD-Derivate:
hd0,1,a= 1. Slice in der 2. Partition der 1. Platte

Die Festplattenreihenfolge wird vom BIOS festgelegt, wobei die im BIOS festgelegte Boot-Platte immer 0x80 (hexadezimal 80, dezimal 128, bei GRUB im allgemeinen als hd0 bezeichnet) erhält und die übrigen Platten danach fortlaufend nummeriert werden.

== Wichtige Konfigurationsdateien von GRUB Legacy==

Die wichtigsten Konfigurations-Dateien von GRUB sind die '''/boot/grub/menu.lst''' und die '''/boot/grub/device.map'''.

Die Datei '''/boot/grub/menu.lst''' ist die Menüdatei und enthält Informationen zu allen Partitionen und Betriebssystemen, welche mit GRUB gebootet werden sollen/können.
'''
Beispiel /boot/grub/menu.lst:'''

color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd1,1)/boot/message

title Linux
kernel (hd1,1)/boot/vmlinuz root=/dev/sdc2 vga=0x317 splash=silent acpi=off desktop resume=/dev/sdc1 showopts
initrd (hd1,1)/boot/initrd

title Windows
root (hd0,0)
chainloader +1

title Diskette
root (fd0)
chainloader +1

title Failsafe
kernel (hd1,1)/boot/vmlinuz root=/dev/sdc2 showopts ide=nodma apm=off acpi=off vga=normal noresume nosmp noapic maxcpus=0 3
initrd (hd1,1)/boot/initrd

title Speichertest
kernel (hd1,1)/boot/memtest.bin

Wichtig für den „Anfangsgebrauch“ sind die Werte für "default" und "timeout": "timeout" gibt an, nach wie vielen Sekunden ohne Eingabe das unter "default" eingestellte Booteintrag ausgeführt werden soll.

Etwas tiefere Einblick in die menu.lst bieten eine Vielzahl Von Artikeln und User Tips <ref>http://www.pro-linux.de/artikel/2/119/der-bootloader-grub.html</ref>

Beim Boot-Vorgang wird die Datei '''/boot/grub/device.map''' nicht verwendet, hier muss mit den Werten gelebt werden, die das BIOS gerade benutzt. Wenn im laufenden Linux-System GRUB-Aktivitäten ausgeführt werden, dient die Datei als Übersetzungtabelle zwischen GRUB- und Linux-Bezeichnung. Es ist zu beachten, dass die GRUB-Bezeichnung in diesem Fall formal nichts mit der BIOS-ID zu tun hat; um Mißverständnisse zu vermeiden, sollte daher dafür gesorgt werden, dass die Werte zusammenpassen (dazu können die Informationen aus dem als ''root'' ausgeführten Befehl
hwinfo --disk | egrep "Device Files:|BIOS id:"
verwendet werden). Wenn die Datei nicht vorhanden ist, wird sie bei der nächsten Ausführung des Programms ''grub'' (das sofort wieder mit "quit" verlassen werden kann) mit vermuteten Werten neu angelegt, die zwar in einfachen Fällen meist mit der jeweiligen BIOS-ID korrespondieren, dies aber nicht tun müssen.

Beispiel /boot/grub/device.map:
(fd0) /dev/fd0
(hd0) /dev/sdc
(hd1) /dev/sdd
(hd2) /dev/sda
(hd3) /dev/sdb

Zur Konfiguration des Bootloader GRUB auf OpenSuse empfielt es sich, ein wenig in der Doku zu blättern. <ref>http://old-de.opensuse.org/SDB:Der_Bootmanager_GRUB</ref>

== Quellen und weiterführende Links ==

* http://www.gnu.org/software/grub/manual/legacy/index.html
* http://www.pl-berichte.de/t_system/grub-howto.html
* http://old-de.opensuse.org/SDB:Der_Bootmanager_GRUB
* http://tldp.org/HOWTO/Multiboot-with-GRUB.html
* http://de.wikipedia.org/wiki/GRUB

-----
Fußnoten:
{|class=wikitable
|
<references/>
|}

----
*[[Bootmanager]]
*[[GRUB]], [[GRUB 2]]

[[Category:Bootmanager]]

GRUB Legacy

2013-12-18T16:32:17Z

Josef-wien: In Sachen device.map muß ich robi korrigieren.

{{Infobox_Software|
Name= GRUB
|Screenshot=
|Beschreibung= Grub Legacy
|Hersteller= Das GRUB-Team
|AktuelleVersion= 0.97
|AktuelleVersionFreigabeDatum= 5/2006
|Betriebssystem= Unix-Derivate, [[Linux]]
|Kategorie= [[Bootmanager]]
|Lizenz= [[GNU General Public License|GPL]]
|Deutsch= nein
|Website= http://www.gnu.org/software/grub/manual/legacy/index.html
}}

== Was ist GRUB Legacy ==

GRUB (Grand Unified Bootloader) ist ein Boot-Manager, der heutzutage bei vielen Linux-Distributionen, wie z.B. Red Hat, [[Mandrake]] und auch [[openSUSE]] per default installiert wird.
GRUB in seiner heutigen Form wird vom GNU Projekt gepflegt und weiterentwickelt.
Aktuell ist [[GRUB 2]] eine komplette Neuentwicklung aus dem selben Team, aber nicht kompatibel zu Grub Legacy.<ref>http://www.gnu.org/software/grub/manual/legacy/index.html</ref>

GRUB Legacy kann verschiedene UNIX-Derivate wie [[Linux]], FreeBSD, NetBSD oder OpenBSD starten und auch das Booten von Windows ist kein Problem.

== Der [[Bootvorgang]] mit GRUB (Legacy)==

''Der Bootloader GRUB startet in 2 Stufen:''

'''Stage1''' befindet sich entweder im Master Boot Record (MBR) der Festplatte oder im Boot-Sektor einer Partition. Die einzige Aufgabe dieser Stufe ist es, '''Stage2''' zu laden.
Stage2 stellt die eigentlichen Funktionen des Bootloaders bereit. Diese befindet sich unter /boot/grub/stage2.

Bei der Installation wird in der Stufe 1 festgeschrieben, an welchem physikalischen Ort sich die Stufe 2 befindet. Befindet sich /boot/grub in bestimmten Dateisystemen, dann wird eine 3 Stufen zwischen Stage1 und Stage2 benötigt, mit deren Hilfe das Dateisystem und somit die Grubdateien gelesen werden können. Hier lädt stage1 die stage1_5, welche Zusatzcode für den Zugriff auf das verwendete Dateisystem enthält, und diese lädt dann stage2.

Stage2 kann dann den Linux-Kernel laden und booten, oder auch andere Betriebssysteme oder andere Bootloader starten.

== Festplattenbezeichnung unter GRUB ==

Die Besonderheit von GRUB ist die Bezeichnung der Festplatten und Partitionen.
Sie unterscheidet sich von der gewohnten Linux-Bezeichnug der Devices.

hd0 = erste Festplatte
hd1 = zweite Festlatte ...

hd0,0 = 1. Partition der ersten Festplatte
hd1,2 = 3. Partition der zweiten Festplatte ...

Für UFS oder UFS2 benutzende Systeme wie Solaris oder BSD-Derivate:
hd0,1,a= 1. Slice in der 2. Partition der 1. Platte

Die Festplattenreihenfolge wird vom BIOS festgelegt, wobei die im BIOS festgelegte Boot-Platte immer 0x80 (hexadezimal 80, dezimal 128, bei GRUB im allgemeinen als hd0 bezeichnet) erhält und die übrigen Platten danach fortlaufend nummeriert werden.

== Wichtige Konfigurationsdateien von GRUB Legacy==

Die wichtigsten Konfigurations-Dateien von GRUB sind die '''/boot/grub/menu.lst''' und die '''/boot/grub/device.map'''.

Die Datei '''/boot/grub/menu.lst''' ist die Menüdatei und enthält Informationen zu allen Partitionen und Betriebssystemen, welche mit GRUB gebootet werden sollen/können.
'''
Beispiel /boot/grub/menu.lst:'''

color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd1,1)/boot/message

title Linux
kernel (hd1,1)/boot/vmlinuz root=/dev/sdc2 vga=0x317 splash=silent acpi=off desktop resume=/dev/sdc1 showopts
initrd (hd1,1)/boot/initrd

title Windows
root (hd0,0)
chainloader +1

title Diskette
root (fd0)
chainloader +1

title Failsafe
kernel (hd1,1)/boot/vmlinuz root=/dev/sdc2 showopts ide=nodma apm=off acpi=off vga=normal noresume nosmp noapic maxcpus=0 3
initrd (hd1,1)/boot/initrd

title Speichertest
kernel (hd1,1)/boot/memtest.bin

Wichtig für den „Anfangsgebrauch“ sind die Werte für "default" und "timeout": "timeout" gibt an, nach wie vielen Sekunden ohne Eingabe das unter "default" eingestellte Booteintrag ausgeführt werden soll.

Etwas tiefere Einblick in die menu.lst bieten eine Vielzahl Von Artikeln und User Tips <ref>http://www.pro-linux.de/artikel/2/119/der-bootloader-grub.html</ref>

Beim Boot-Vorgang wird die Datei device.map nicht verwendet, hier muss mit den Werten gelebt werden, die das BIOS gerade benutzt. Wenn im laufenden Linux-System GRUB-Aktivitäten ausgeführt werden, dient die Datei device.map als Übersetzungtabelle zwischen GRUB- und Linux-Bezeichnung. Es ist zu beachten, daß die GRUB-Bezeichnung in diesem Fall formal nichts mit der BIOS-ID zu tun hat, um Mißverständnisse zu vermeiden sollte jedoch dafür gesorgt werden, daß die Werte zusammenpassen (dazu können die Informationen aus dem als ''root'' ausgeführten Befehl
hwinfo --disk | egrep "Device Files:|BIOS id:"
verwendet werden). Wenn die Datei nicht vorhanden ist, wird sie bei der nächsten Ausführung des Programms ''grub'' (das sofort wieder mit "quit" verlassen werden kann) mit vermuteten Werten neu angelegt, die keineswegs der BIOS-ID entsprechen müssen.

Muster einer device.map:
(fd0) /dev/fd0
(hd0) /dev/sdc
(hd1) /dev/sdd
(hd2) /dev/sda
(hd3) /dev/sdb

Zur Konfiguration des Bootloader GRUB auf OpenSuse empfielt es sich, ein wenig in der Doku zu blättern. <ref>http://old-de.opensuse.org/SDB:Der_Bootmanager_GRUB</ref>

== Quellen und weiterführende Links ==

* http://www.gnu.org/software/grub/manual/legacy/index.html
* http://www.pl-berichte.de/t_system/grub-howto.html
* http://old-de.opensuse.org/SDB:Der_Bootmanager_GRUB
* http://tldp.org/HOWTO/Multiboot-with-GRUB.html
* http://de.wikipedia.org/wiki/GRUB

-----
Fußnoten:
{|class=wikitable
|
<references/>
|}

----
*[[Bootmanager]]
*[[GRUB]], [[GRUB 2]]

[[Category:Bootmanager]]

Diskussion:GRUB Legacy

2013-12-17T23:03:35Z

Josef-wien: Neuer Abschnitt /* 1. Verweise im Dokument - 2. Device-Angaben */

Wenn man auf einer Seite die Rechtschreibung korrigiert, dann sollte man auch das Wort "Rechtschreibung" im Versionshinweis richtig schreiben! --[[Benutzer:Admine|Admine]]

:Ich wollte den Rechtschreibfehler nicht einfach so stehen lassen. Habe ich damit einen Fehler begangen?
:"Rechtschreibunk" anstatt "Rechtschreibung" in einem '''Versionshinweis''' - das war nur spaßig gemeint. Ist das echt ein Problem? --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 11:21, 12. Dez. 2013 (CET)

:: Du hast mit dem Korrigieren keinen Fehler begangen, aber der Spaß im Versionshinweis ... ? Hab ich so nicht gesehen. --[[Benutzer:Admine|Admine]]

=Inhalt von Seite GRUB übernommen=
Dies ist Content GRUB v1 alias GRUB Legacy betreffend. Mit GRUB 2 ergibt sich die Notwendigkeit, dies zu differenzieren. Das soll zukünftig auf der Seite GRUB geschehen, wo dann Links zu beiden Versionen existieren werden. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 15:03, 7. Dez. 2013 (CET)

== 1. Verweise im Dokument - 2. Device-Angaben ==

Angaben wie '''[1]''' nützen nichts. Falls damit irgendwelche Eintragungen bei "Quellen und weiterführende Links" gemeint sein sollten, müssen sich die Ziffern dort wiederfinden, oder es muß eine andere Lösung gefunden werden.

Die veralteten Linux-Angaben /dev/'''h'''dX[Y] habe ich vorerst drinnen gelassen, ich finde aber, sie gehören hinaus.

M.f.G. Josef

GRUB Legacy

2013-12-17T22:54:47Z

Josef-wien: notwendige Korrekturen vorgenommen

{{Infobox_Software|
Name= GRUB
|Screenshot=
|Beschreibung= Grub Legacy
|Hersteller= Das GRUB-Team
|AktuelleVersion= 0.97
|AktuelleVersionFreigabeDatum= 5/2006
|Betriebssystem= Unix-Derivate, [[Linux]]
|Kategorie= [[Bootmanager]]
|Lizenz= [[GNU General Public License|GPL]]
|Deutsch= nein
|Website= http://www.gnu.org/software/grub/manual/legacy/index.html
}}

== Was ist GRUB Legacy ==

GRUB (Grand Unified Bootloader) ist ein Boot-Manager, der heutzutage bei vielen Linux-Distributionen, wie z.B. Red Hat, [[Mandrake]] und auch [[openSUSE]] per default installiert wird.
GRUB in seiner heutigen Form wird vom GNU Projekt gepflegt und weiterentwickelt. '''[1]'''
Aktuell ist [[GRUB 2]] eine komplette Neuentwicklung aus dem selben Team, aber nicht kompatibel zu Grub Legacy.

GRUB Legacy kann verschiedene UNIX-Derivate wie [[Linux]], FreeBSD, NetBSD oder OpenBSD starten und auch das Booten von Windows ist kein Problem.

== Der [[Bootvorgang]] mit GRUB (Legacy)==

''GRUB besteht aus 2 Stufen:''

stage1 befindet sich entweder im Master Boot Record (MBR) der Festplatte oder im Boot-Sektor einer Partition. Die einzige Aufgabe dieser Stufe ist es, stage2 zu laden.
stage2 stellt die eigentlichen Funktionen des Bootloaders bereit. Diese befindet sich unter /boot/grub/stage2.

Bei der Installation wird in der Stufe 1 festgeschrieben, an welchem physikalischen Ort sich die Stufe 2 befindet. Es gibt auch Systeme, die in 3 Stufen gebootet werden. Hier lädt stage1 die stage1_5, welche Zusatzcode für den Zugriff auf das verwendete Dateisystem enthält, diese lädt dann wiederrum stage2.

== Festplattenbezeichnung unter GRUB ==

Die Besonderheit von GRUB ist die Bezeichnung der Festplatten und Partitionen.
Sie unterscheidet sich von der gewohnten Linux-Bezeichnug der Devices. '''[2]'''

hd0 = erste Festplatte
hd1 = zweite Festlatte ...

hd0,0 = 1. Partition der ersten Festplatte
hd1,2 = 3. Partition der zweiten Festplatte ...

Für UFS oder UFS2 benutzende Systeme wie Solaris oder BSD-Derivate:
hd0,1,a= 1. Slice in der 2. Partition der 1. Platte

Die Festplattenreihenfolge wird vom BIOS festgelegt, wobei die im BIOS festgelegte Boot-Platte immer 0x80 (hexadezimal 80, dezimal 128, bei GRUB im allgemeinen als hd0 bezeichnet) erhält und die übrigen Platten danach fortlaufend nummeriert werden.

== Wichtige Konfigurationsdateien von GRUB Legacy==

Die wichtigsten Konfigurations-Dateien von GRUB sind die menu.lst und die device.map. Beide zu finden in /boot/grub.

Die menu.lst ist die Menüdatei und enthält Informationen zu allen Partitionen und Betriebssystemen, welche mit GRUB gebootet werden sollen/können.

Beispiel /boot/grub/menu.lst:

color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd1,1)/boot/message

title Linux
kernel (hd1,1)/boot/vmlinuz root=/dev/hdf2 vga=0x317 splash=silent acpi=off desktop resume=/dev/hdf1 showopts
initrd (hd1,1)/boot/initrd

title Windows
root (hd0,0)
chainloader +1

title Diskette
root (fd0)
chainloader +1

title Failsafe
kernel (hd1,1)/boot/vmlinuz root=/dev/hdf2 showopts ide=nodma apm=off acpi=off vga=normal noresume nosmp noapic maxcpus=0 3
initrd (hd1,1)/boot/initrd

title Speichertest
kernel (hd1,1)/boot/memtest.bin

Wichtig für den „Anfangsgebrauch“ sind die Werte für "default" und "timeout": "timeout" gibt an, nach wievielen Sekunden ohne Eingabe das unter "default" eingestellte System gebootet wird.

Um einen tieferen Einblick in die menu.lst zu bekommen, lohnt es sich, einen Augenblick Zeit zu nehmen und '''[3]''' zu lesen.

Wenn im laufenden Linux-System GRUB-Aktivitäten ausgeführt werden, dient die Datei device.map als Übersetzungtabelle zwischen GRUB- und Linux-Bezeichnung, z. B.:

(fd0) /dev/fd0
(hd0) /dev/hda
(hd1) /dev/hdb
(hd2) /dev/sda
(hd3) /dev/sdb

Beim Boot-Vorgang spielt diese Datei nicht mit.

Zur Konfiguration des Bootloader GRUB empfielt es sich, den Text '''[4]''' zu lesen.

== Quellen und weiterführende Links ==

* http://www.gnu.org/software/grub/manual/legacy/index.html
* http://www.linux-club.de/viewtopic.php?t=4949
* http://www.kofler.cc/pdf/linux7_kapitel26.pdf
* http://www.pl-berichte.de/t_system/grub-howto.html
* http://de.opensuse.org/SDB:Der_Bootmanager_GRUB
* http://www.linuxgazette.com/issue64/kohli.html
* http://tldp.org/HOWTO/Multiboot-with-GRUB.html
* http://de.wikipedia.org/wiki/GRUB

Created by [[l:Benutzer:Funny|michiSPO]]

Freundlichst für den LC zur Verfügung gestellt und vom Linux-Club richtiggestellt.
----
*[[Bootmanager]]
*[[GRUB]], [[GRUB 2]]

[[Category:Bootmanager]]

Zwei Kernel parallel installieren

2013-11-25T09:46:17Z

Josef-wien: Hinweis auf die standardmäßige Aktivierung ab openSUSE 12.3

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1, 11.3, 11.4, 12.1, 12.3
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln. D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

Mit Ausnahme von openSUSE 11.1 besteht der kompilierte Kernel aus einer *.rpm-Datei. Bei openSUSE 11.1 sind es mit Ausnahme des Vanilla-Kernel drei *.rpm-Dateien (kernel-xxx, kernel-xxx-base und kernel-xxx-extra, xxx steht für den Kernel-Typ, z.B. default), die als Einheit betrachtet werden sollen; die Datei kernel-xxx-extra sollte nur dann weggelassen werden, wenn man ganz sicher ist, diese Module nicht zu benötigen. Ab openSUSE 11.2 ist das Paket kernel-xxx-base nur eine relativ kleine Teilmenge von kernel-xxx und für den normalen Anwender nicht zielführend.

== Bevorzugte Variante ==

Seit einigen openSUSE-Versionen ist es möglich, mit zypper (und damit auch mit YaST) mehrere Kernel desselben Typs zu installieren. Dazu muss in der Datei /etc/zypp/zypp.conf die Zeile
multiversion = provides:multiversion(kernel)
aktiviert werden.

Ab openSUSE 12.3 ist diese Einstellung standardmäßig aktiviert, die Anzahl der gleichzeitig installierten Kernel wird durch die Angabe
multiversion.kernels = ...
festgelegt, die möglichen Werte sind in der Datei /etc/zypp/zypp.conf angeführt.

== Früher notwendige Varianten ==

=== Erste Variante ===

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

=== Zweite Variante ===

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

Unter openSUSE 11.1 ist diese Variante aufgrund von Abhängigkeitsproblem leider nicht mehr möglich.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Ab openSUSE 11.1 (und möglicherweise früher) genügt es jetzt im Normalfall zu überprüfen, ob der Kernel in <code>/boot/grub/menu.lst</code> richtig eingetragen wurde. Nur bei älteren Versionen ist es wichtig zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>. Neuere openSUSE-Versionen schreiben nämlich nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>. Bei Bedarf muss darum zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

Hilfe zu Antworten aus dem Forum

2012-12-21T17:04:03Z

Josef-wien: Erweiterung des Punkts 1.2 um eine Anleitung zum manuellen Einhängen.

Du hast Linux das erste Mal installiert, irgend etwas funktioniert nicht, also hast du eine Frage ins Forum gesetzt. Mit der Antwort kannst du jedoch überhaupt nichts anfangen. Ein Antwortender im Forum kann nicht immer einschätzen, welche Vorkenntnisse du mitbringst, und da kann es schon mal passieren, dass du eine kurze und knappe Antwort bekommst. Deshalb hier mal einige häufige Probleme mit den Antworten aus dem Forum.

== gib mal folgendes ein ==

'''Der Anworter möchte, dass du in einer der Konsolen einen Befehl eingibst, hat aber übersehen, dass du dich gar nicht anmelden kannst, und du noch nie etwas von einer Konsole gehört hast. Wo sollst du denn jetzt den Befehl oder die Zeile eingeben ?????
'''

Linux ist voll über die [http://www.bin-bash.de/index.php Komandozeile steuer- und bedienbar], die grafische Oberfläche ist quasi nur oben draufgelegt. Dort hin kannst du dich deshalb auch jederzeit bei Problemen hinretten. Es gibt verschiedene Möglichkeiten um dort hin zu gelangen. Erwarten tut dich dort eine Konsole, die ähnlich funktioniert wie die DOS-Kommandozeile innherhalb von Windows. Dort arbeitet eine Shell, die deine Eingaben entgegennimmt und ausführt. Ganz am Anfang wirst du wahrscheinlich ein paar Fragen haben wie zb [http://www.bin-bash.de/kommando.php Grundkommandos und Einführung] sowie [http://www.bin-bash.de/dateisystem.php Einführung in das Dateisystem] und [http://www.bin-bash.de/editor.php Editoren für die Konsole], dich aber schon nach kurzer Zeit einigermaßen zurechtfinden.

Viele Linuxdistributionen starten beim Booten mehrere unabhängige Terminals oder Konsolen. Du erreichst sie mit den Tastenkombinationen '''STRG+ALT+F1''' bei Suse zB bis '''STRG+ALT+F6''' und kannst mit diesen Tastenkombinationen jederzeit dort hin und her wechseln. Auf der ersten Konsole sind auch die letzten Bootausgaben wahrscheinlich noch sichtbar. Mit der Tastenkombination '''STRG+ALT+F7''' würdest du die erste Grafische Oberfläche finden, bei '''STRG+ALT+F8''' eine eventuell zusätzlich gestartete 2 Grafische Oberfläche. Bei einigen Distributionen findest du auch noch einen Systemlog, bei Suse zB auf '''STRG+ALT+F10'''.

An den Konsolen musst du dich mit einem Usernamen und einem Passwort anmelden. '''Achtung: das Passwort muss dort blind eingegeben werden. es erscheinen also keine ****** und der Cursor bewegt sich dabei auch nicht.''' Bestätigen natürlich mit ENTER :-)

Innerhalb der Grafischen Oberflächen gibt es mehrere Programme, die auch Terminals und Konsolen als Fenster innerhalb der Grafischen Oberfläche bereitstellen, Dort brauchst du dich nicht anzumelden, da sie eindeutig dem Benutzer der grafischen Oberfläche zugeordnet werden, und der hat sich zu diesem Zeitpunkt schon angemeldet.
Diese Programme findest du zB unter Menüpunkten wie '''System -> Terminals''' und könnten '''xterm''' oder einfach nur '''terminal''' heißen.

=== Die Konsolausgabe ins Forum posten ===

Dazu ist es am besten, wenn ihr ein X-Terminal, also ein Konsolfenster innerhalb der Grafischen Oberfläche öffnen könnt. Dort dann den Befehl ausführen und die Ausgabe markieren. Entweder könnt ihr das markierte dann direkt im Webbrowser in eure Antwort einfügen (oft mittlere Maustaste) oder über '''copy''' beim xterminal und '''paste''' im Browser einfügen. Bitte nicht vergessen, das ganze in [code] [/code] einzuschließen, damit es im Forum vernünftig aussieht und leichter lesbar ist.

=== Konsolausgabe ins Forum posten, wenn Grafisch nichts geht ===

Wenn keine grafische Oberfläche startbar ist und ihr deshalb auch keinen Browser auf diesem Rechner habt, mit dem ihr direkt posten könnt, auch kein zweiter Rechner da ist, mit dem [[Mit putty und ssh key auf einen sicheren Linux Server zugreifen|remote auf diesen Rechner zugreifen]] kann, wird es etwas komplizierter.
Solange Linux ansonsten voll einsatz- und funktionstüchtig ist, sollte es in den meisten Fällen möglich sein, einen USB-Stick oder eine SD-Karte oä. an das System anzuschließen. Einfach einmal anschließen und 10 Sekunden warten. Anschließend (bei Suse) auf der Konsole mal mit '''cd''' in das Verzeichnis '''/media''' wechseln und dort mit '''ls''' etwas umsehen.
Die Schritte im einzelnen:
Konsole wie oben beschrieben öffen und anmelden. ZB einen USB-Sick anschließen
cd /media
ls
Als Ergebniss erhaltet ihr wahrscheinlich bei Erfolg irgend so was hier.
.hal-mtab .hal-mtab-lock disk
Von interesse ist hier im Beispiel das Verzeichnis '''disk''', das kann aber bei euch auch ganz anders heißen, könnte zB den Namen eures USB-Sticks haben und es könnten sich auch noch mehrere dort befinden. In dieses Verzeichnis wechseln und dort umschauen, was es für Dateien dort schon gibt.
cd disk
ls
'''Bei aktuellen Distributionen''' ist das Einhängen von Wechseldatenträgern eine Dienstleistung der jeweiligen grafischen Oberfläche, daher ist das Verzeichnis '''/media''' üblicherweise leer. Das Einhängen ist '''manuell''' vorzunehmen. Mit dem als root ausgeführten Befehl
ls -l /dev/disk/by-id/usb*
kann der USB-Stick identifiziert werden, die rechts stehende ''device'' /dev/sdXY der Partition wird zum Einhängen verwendet:
mount /dev/sdXY /media
(X und Y sind der Ausgabe des ls-Befehls zu entnehmen).

Jetzt könnt ihr euren Befehl eingeben, dessen Ausgabe hier gewünscht wird. Die Ausgabe erhaltet ihr erstmal auf der Konsole, das nützt noch wenig.
Den Befehl noch einmal eingeben und hinter den Befehl '''> Dateinam.txt''' schreiben. Wobei '''Dateinam.txt''' ein von euch frei wählbarer Dateiname ist, der natürlich nicht schon vorhanden Dateien auf dem USB-Stick überschreiben sollte, also aufpassen, welchen Dateinamen ihr wählt.
befehl > Dateinam.txt
eine eventuelle Fehlermeldung würde dabei nicht mit in die Datei geschrieben, sondern würde weiterhin auf der Konsole landen. Oftmals ist auch diese Fehlermeldung noch von Interesse. Sowohl die normale Befehlsausgabe als auch die Fehlerausgabe in eine Datei umleiten geht zB wie folgt.
befehl > Dateiname.txt 2>&1
Den Erfolg könnt ihr euch schon mal anschauen, indem ihr eure angelegte Datei mal probehalber auslest.
cat Dateinam.txt
sollte das selbe anzeigen wie vorhin der Befehl ohne die Umleitung in die Datei. 
sollte der geforderte Befehl in einem bestimmten Verzeichnis des Rechner abgegeben werden müssen, dann einfach beim Dateinamen den vollen Verzeichnispfad zu der Datei auf dem USB-Stick angeben zB
befehl > /media/disk/Dateinam.txt
ausleseen dann analog, (Das ist dann auch der Befehl, um das auf einem anderen Linuxrechner wieder von konsole auszulesen. Bei längeren Dateien ist jedoch '''more''' besser, da man dann im Text besser navigieren kann.)
cat /media/disk/Dateinam.txt
Werden Informationen von mehreren Befehlen benötigt ist es natürlich sehr mühselig die Ausgaben alle einzeln in Dateien umzuleiten. Auf vielen Linuxsystemen sollte es den Befehl [http://linux.die.net/man/1/script script] geben. Damit lassen sich ganz automatisch alle Ausgaben von der Konsole parallel auch in eine Datei schreiben. Aufruf zB.
script dateiname.log
Jetzt werden alle Ausgaben automatisch auch in die Datei '''dateiname.log''' geschrieben. Wenn es auf den USB-Stick soll, müsst ihr natürlich den kompletten Verzeichnisbaum zur Datei auf dem USB-Stick mit angeben. Beendet wird das ganze mit dem Schließen der aktuellen Shell also zB durch '''exit''' oder '''STRG + D'''

An dieser Stelle jetzt aber nicht einfach den USB-Stick entfernen. Für den absolut unerfahrenen Anfänger hier am besten den Rechner herunterfahren, ihr werdet den Rechner wahrscheinlich sowieso mit einem anderen Betriebssystem benötigen. Runterfahren geht nur als User root
Befehle dazu in absteigender Reihenfolge ausprobieren.
shutdown -h now
init 0
halt

eventuell auch STRG+ALT+ENTF. Irgendetwas davon sollte funktionieren und den Rechner ausschalten.

Wenn das Einhängen wie oben beschrieben '''manuell''' erfolgt ist, kann der USB-Stick nach Durchführung der Befehle
sync
umount /media
entfernt werden.

Jetzt könnt ihr euren Rechner zB mit Windows starten und die Datei auf dem USB-Stick auslesen und hier her posten. Die Datei bitte mit WordPad offnen, da sonst eventuell das Format nicht als Unix erkannt wird und alles in einer Zeile steht.

=== Konsolausgabe ins Forum posten wenn der Rechner beim booten hängen bleibt ===

Wenn der Rechner früh hängen bleibt und somit die Dienste noch nicht laufen die zB automatisch USB einbinden. Ist eventuell das Rootfilesystem "'''/'''" schon zum schreiben geöffnet. Ihr müsst euch hier wahrscheinlich sowieso erstmal als Root anmelden.
Testen ob das Root-Verzeichnis schreibbar ist geht mit dem Befehl '''mount'''
Kommt als Ergebnis unter anderen folgende Zeile
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
Die Zeile wird bei euch etwas anders aussehen. Wichtig ist das '''"/"''' hinter '''on''' das ist das Rootfilesystem und die Option '''"rw"''' in der Klammer, die sowie bedeutet wie Read-Write also Lesen und Schreiben. Das Gegenteil davon währe '''"ro"''' (Readonly) also nur Lesbar

Ist dieses Dateisystem zum Schreiben geöffnet, so kann auch eine Datei darin angelegt werden, in der ihr die Ausgabe des Befehles umleiten könnt, wie steht etwas weiter oben. Als Ablageort empfiehlt sich das Verzeichnis /tmp , also zB nach '''> /tmp/Dateinam.txt''' als Umleitung für die Ausgaben nutzen, dann sollte es auf den meisten Rechnern im Rootfilesystem im Verzeichnis /tmp ankommen.
Den Inhalt dieser Datei könntest ihr zB dann aus einem Livesystem heraus ins Forum posten.

Ist das Rootfilesystem nur zum Lesen eingebunden, (dann wird wohl erstmal ein [[Hilfe zu Antworten aus dem Forum#mach mal fsck irgendwas|Filesystemcheck]] angebracht sein.)

=== Konsolausgabe ins Forum posten wenn gar nichts mehr geht ===

Im frühen oder sehr frühem Bootstatus sind vor allem die Meldungen und Fehlerausgaben des Rechner von interesse.
Zwar wird es in den meisten Fällen durchaus möglich sein, sich diese Ausgaben über ein Null-Modem-Kabel in eine Terminalemulation eines anderen Rechners einzulesen, aber das ist eine Option ehr für die Profis und solche die schon wissen was ein Null-Modem-Kabel überhaupt ist. ;-)

In den meisten Fällen müßte hier also die Ausgabe des Rechners oder die Fehlermeldung wirklich abgeschrieben werden und dann von einem anderem Rechner gepostet werden. Aber bitte in solchen Fällen möglichst genau abschreiben und nicht "Error irgendwas Parition" damit kann niemand wirklich was anfangen.
Hin und wieder war es auch recht nützlich einfach den Bildschirm zu fotografieren und den Link auf das Foto ins Forum zu posten. Wenn wirklich die relevante Fehler-Meldung
dabei rüberkommt, ist es immerhin noch eine Alternative, wenn auch nicht die Schönste.

== als root folgendes eingeben ==

'''Der Antwortende möchte, das du auf einer Konsole, siehe oben, eine Eingabe unter einer bestimmten User-Kennung vornimmst, und zwar die des Systemadministrators.'''

Der System-Administrator und Linux und anderen Unix-Betriebssytemen heißt immer '''root'''. Diese Userkennung hat so gut wie keinerlei Beschränkungen, bzw. könnte sich mit eventuellen weiteren Befehlen über jede Beschränkung innerhalb des Betriebssystems hinweg setzten, so das dieser User alles mit dem Rechner machen könnte. Viele Systemverwalter Befehle können nur mit dieser Userkennung ausgeführt werden, und auch an einige wichtige Logdateien kommt man ohne diese Userkennung gar nicht heran. [[Permanent root sein|Ein permanentes Arbeiten unter Linux unter dieser Kennung ist allerdings sehr gefährlich]]. Ein Root-Passwort wird schon während der Installation abgefragt und vergeben, und wird natürlich für die Anmeldung oder eines Userwechsels benötigt.

Also entweder man meldet sich auf einer Konsole in der Anmeldung als User root an, oder wechselt mit dem Befehl
su -
innerhalb einer Userkonsolsitzung den User. Abmelden dann nicht vergessen. also entweder '''exit''' oder '''STRG+D''' beendet eine so geöffnete Shell, und man kann als normaler User weiterarbeiten. Weitere Möglichkeiten als root Befehle oder Progamme auszuführen gibt es ebenfalls [[Permanent root sein|hier]]

== man irgendwas ==

'''Der Antworter möchte dich darauf aufmerksam machen, dass die Antwort auf deinen Frage in der Dokumentation leicht zu finden ist'''

Auch Hinweise wie '''[http://lug-s.org/dokumentation/kurse/linux/extra/rtfm.html RTFM]''' oder Schlagworte wie '''Manpage''' gehen genau in diese Richtung. Linux bringt anders als Windows ein sehr umfangreiches Hilfesystem und Beschreibung für die meisten Befehle gleich mit. Bei den meisten Distributionen werden umfangreichte Dokumentationen und Hilfen schon bei der Installation angelegt bzw. sie werden mit den einzelnen Programmpaketen mit installiert. Es gibt die '''Manpages''', die '''Infoseiten''' einprogramierte '''Help-Option''' in sehr vielen Befehlen und zusätzlich noch Dokumentationen und Howtos die oft schon auf deinem Rechner mit installiert sind.

Eine Einführung in die [[Man pages|Nutzung der Online Hilfe]] weiter [[Einfuehrung in SuSE-Linux für Newbies| hilfreiche Links für Neulinge]] und die [[OpenSUSE Handbücher| Links zu den Handbüchern]] gibts hier im Wiki

== was sagt denn irgendwas ==

'''Es gibt eine ganze Reihe sehr häufig im Forum für eine Hilfe erforderliche Dateiinhalte oder Ausgaben von Befehlen, oftmals wird vom Antworter vorausgesetzt das beim Schlagwort bekannt ist, ob es sich um einen Befehl oder eine Datei handelt und das auch die genaue Position innerhalb des Dateisystems bekannt ist, sowie der Befehl zur Ausgabe des Dateiinhaltes'''

Das Problem hierbei, es ist für einen absoluten Neuling manchmal überhaupt nicht ersichtlich, handelt es sich nun um eine Datei oder einen Befehl, oder um irgend ein Programm, hier mal einige häufige Schlagworte in Tabellenübersicht, eine solche Tabelle kann aber nie vollständig werden, desshalb im Zweifelsfall mal nach diesem Schlagwort innerhalb des Forums mit der Suchfunktion suchen.

{| Border=1
|+ '''Schagworte und was damit anfangen'''
! Schlagwort !! Type !! was tun !! Bedeutung des Inhaltes der Ausgabe

|-
! df
||Befehl||als normaler User in einer Konsole ausführen
|| zeigt die Größe und die belegte und verfügbare Kapazität der Filesysteme an

|-
! ls
||Befehl||als normaler User in einer Konsole ausführen, eventuell muss vorher mit dem Befehl [http://www.bin-bash.de/kommando.php cd] erst in das betreffende Verzeichnis gewechselt werden <ref name="Option ls"> wird oft mit der Option "-l" benutzt, es handelt sich dabei um ein kleines "L" nicht um eine "1" oder um ein Großes "i" </ref>
|| listet die Dateien des aktuellen Verzeichnisses auf

|-
! mount
||Befehl||als normaler User in einer Konsole ausführen
|| zeigt wenn keine weiteren Optionen verwendet werden die aktuelle ins System integrierten Dateisysteme, (sind weiter Optionen dort angegeben siehe [[#mounte oder umounte mal irgendwas|hier]])

|-
! fstab
||Datei||"'''cat /etc/fstab'''" in Konsole ausführen
|| enthält die Konfiguration der Dateisysteme

|-
! menu.lst
|| Datei || "'''cat /boot/grub/menu.lst'''" als Root in Konsole auführen
|| enthält die Konfiguration des Bootloaders Grub der heute meistens verwendet wird

|-
! device.map
|| Datei || "'''cat /boot/grub/device.map'''" als Root in Konsole ausführen
|| enthält eine Zuordnung der vom Bios gemeldeten Plattenreihenfolge für den Bootloader Grub

|-
! grub.conf
|| Datei || "'''cat /etc/grub.conf'''" als Root in Konsole ausführen
|| enthält eine Suse-Yast-typische Konfigurationsdatei für den Bootloader, deren Inhalt hin und wieder für bestimmte Bootprobleme verantwortlich ist.

|-
! dmesg
||Befehl||als user in Konsole ausführen <ref name="lange Datei">Die Ausgabe wird sehr umfangreich, ohne spezielle Kenntnisse wird es oft schwer wirklich die relevanten Informationen da herauszufinden, sind keine speziellen Fehler, keine anderen Auswahlkriterien oder der Dateianfang oder -ende gemeint, dann bitte keine Monsterpostings sondern erst mal [http://www.linux-club.de/viewtopic.php?f=48&t=67358 hier] lesen </ref>
||enthält die Meldungen des Linuxkernels seit dem booten

|-
! messages
||Datei||"'''cat /var/log/messages'''" als root in Konsole ausführen <ref name="lange Datei"> </ref>
|| enthält den Großteil der gesammelten Logs des Systems

|-
! fdisk
||Befehl||"'''fdisk -l'''" in Konsole als root ausführen <ref name="Option ls"> </ref>
|| gibt die Partitionstabellen aller im System befindlicher Festplatten aus

|-
! lspci
|| Befehl|| "'''lspci'''" in Konsole als root ausführen <ref name="Optionen"> wird manchmal auch mit weiteren Optionen benötigt </ref>
|| listet die sich im Rechner befindenden PCI-Geräte und Kontroller auf, die Ausgabe ist stark abhängig eventueller weiter Optionen

|-
! lsusb
|| Befehl|| "'''lsusb'''" in Konsole als root ausführen <ref name="Optionen"> </ref>
|| listet die sich am Rechner befindenden USB-Geräte auf
|}

Benötigt wird in den allermeisten Fällen eine wirklich genaue Ausgabe solcher Befehle und Dateien bzw. Teilen davon. Die Ausgaben also möglichst nicht abschreiben sondern kopieren und einfügen und hier als Code-markiert (in Ausnahmen auch also Quote-markiert) ins Forum posten. Es kommt besonders bei Konfigurationen und Fehlermeldungen gelegentlich auf winzige Kleinigkeiten an. In vielen Fällen werden die Ausgaben so lang, dass sie nicht auf eine Bildschirm-Seite passen. Für das direkte posten ins Forum sind sie dann meist sowieso zu lang <ref name="lange Datei"> </ref> , aber ihr habt bestimmt von Antworter einen Hinweis erhalten nach was ihr in der Ausgabe Ausschau halten sollt. Im Zweifelsfall sind es Zeilen mit '''ERROR''' oder ähnlichen Auffälligkeiten oder sich ständig wiederholende Zeileninhalte. Es gibt dafür 2 prinzipielle Lösungen, entweder ihr schreibt die Ausgabe des Befehles nicht auf den Bildschirm sondern in eine Datei, und schaut euch diese dann anschließend an. Dazu auf der Konsole an das Ende des Befehles ein Umleitungssymbol "''' > '''" und den gewünschten Dateinamen also zB. um die Kernelmeldungen seit dem booten des Rechners in die Datei '''/tmp/boot.log''' zu schreiben, um sie später anzuschauen.
dmesg > /tmp/boot.log

die andere Möglichkeit, einen Pager verwenden, der euch einen seitenweise Anzeige ermöglicht. Häufig wird unter Linux [http://linux.die.net/man/1/more more] verwendet. Bei Dateien einfach die Datei mit '''more''' öffnen.
more Datei
bei Konsolausgaben die Ausgabe eines Befehles durch einen Pipe "''' |''' " an '''more''' übergeben
dmesg | more
Zeilenweise nach vorne geht es dann mit '''Enter''', Seitenweise mit der Leertaste oder mit '''z''' und Beenden mit '''q''' (wie Quit). Hilfe gibt es mit '''h''' . Weitere Grundlagen zu Ausgabeumleitung findet ihr auch [http://www.bin-bash.de/komfort.php hier]

== mach mal init 3 ==

'''Oftmals in Verbindung mit Grafikartenproblemen, der Antworter will dir damit sagen, du sollst mal den Runlevel ändern.'''

Es gibt im Linux verschiedene Systemzustände ([http://de.wikipedia.org/wiki/Runlevel Runlevel]). Nach der Installation von Linux auf Desktop-Rechnern wird im Normalfall automatisch Runlevel 5 gestartet, der die grafische Oberfläche startet. Gibt es hier direkt nach der Installation zB Problem mit der Grafikkarte, ist es oftmals erforderlich zur Diagnose und Behebung des Fehlers den Runlevel zu ändern. Runlevel 3 würde bedeuten, volle Funktion des Rechners aber grafische Oberfläche nicht automatisch starten. Zum ändern des Runlevels eines laufenden Rechners dann zuerst einmal auf eine [[ #gib mal folgendes ein|Konsole wechseln]] also zB '''STRG+ALT+F2''' und dort als root anmelden. Dann dort in der Konsole folgenden Befehl abgeben
init 3
eine andere Möglichkeit den Rechner beim booten anweisen in den Runlevel 3 zu starten. Wenn nach dem einschalten des Rechners sich der Bootloader mit dem Menü meldet, dann in die Zeile für Bootoptionen nur eine
3
am Ende zusätzlich reinschreiben und mit Enter das System starten. Der Rechner wird jetzt den Runlevel 3 starten und euch auf einer Konsole mit einer Loginaufforderung begrüßen. Von hier könnt ihr jetzt nach der Anmeldung die Befehle ausführen die der Antworter euch vorgeschlagen hat.

Nach erfolgreicher Reparatur oder Umkonfiguration der Grafikarte könnte ihr von dort aus direkt mit
init 5
wieder den normalen Runlevel und damit die grafische Oberfläche starten.

== mounte oder umounte mal irgendwas ==

'''Der Antworter möchte dir damit sagen, du sollst mal am Dateibaum von Linux ein Filesystem zusätzlich einhängen oder aushängen, um zB eine Datei auf einem anderem derzeit nicht zugänglichen Filesystem auslesen zu können'''

Es ist ein etwas komplexes Thema und eine etwas umfangreichere Einführung gibt es [http://www.bin-bash.de/dateisystem.php hier]. An dieser Stelle nur ein Universal-Konzentrat ohne Tiefgang.

Linux verwendet einen verzweigten [http://www.selflinux.org/selflinux/html/verzeichnisse_unter_linux01.html Dateibaum], in dem alle Filesysteme integriert sind, und der beliebig erweiterbar ist. Normalerweise erledigt das Linux automatisch über eine Konfigurationsdatei ('''/etc/fstab''') oder über Funktionen des Plug & Play Systems. Manchmal sollen jedoch auch mal auf die Schnelle unkonfigurierte Filesysteme aus irgend einen Grund kurzzeitig eingehängt werden. Das Filesystem ist dann das '''irgendwas''' in der obrigen Aufforderung, und befindet sich in der Regel auf einer Partition eines Datenträgers, und dieser Name wird gebraucht, oder ist euch genannt worden.
Auf neueren Susesystemen sind folgende Namen für Datenträger zu erwarten (zB : '''sda''' ist die erste Platte '''sdb''' die zweite usw. und Partitionsbezeichnungen wird als Zahl dahinter gesetzt. ('''sdd3''' ist also die 4 Platte die dritte Partition)

Der Name allein reicht nicht, wir brauchen den Geräteknoten von Linux dazu. Das ist eine spezielle Datei selbigen Namens die sich im Verzeichnis '''/dev''' befindet.
Für das Filesystem auf der 4. Platte in der 3. Partition ergibt sich also der komplette Name '''"/dev/sdd3'''" als das komplette ''irgendwas'' was wir benötigen.

Wir benötigen noch eine leeres Verzeichnis als den Einhängepunkt unseres Filesystems. Linux hat für den temporären Gebrauch dafür schon eines vorgesehen '''/mnt'''

Der Befehl dazu lautet '''mount''' und ist in diesem Fall als '''root''' auszuführen. Meist reicht er so.
mount /dev/sdd3 /mnt
Also Filesystem 4.Platte 3.Partition in /mnt einhängen. Die Dateien in dem Filesystem sind dann unter ihrem Namen mit vorgestelltem /mnt zu erreichen. also die Datei '''bild1''' im Verzeichnis '''bilder''' in diesem Dateisystem als '''/mnt/bilder/bild1'''. Oder man wechselt das Verzeichnis mit '''cd''' in das entsprechende Verzeichnis.
cd /mnt/bilder

Aushängen geht dann ähnlich, wir benötigen dafür allerdings nur entweder unser komplettes irgendwas oder das Verzeichnis in das das Filesystem eingehängt ist. Der Befehl dazu lautet '''umount'''
umount /mnt
würde das oben eingehängte Filesystem also wieder aushängen. ( Voraussetzung dafür das das funktioniet ist jedoch, das derzeit niemand mehr auf eine Datei dieses Filesystems zugreift und wir auch nicht selbst uns noch mit dem aktuellem Dateisystemabschnitt aufhalten ) Im Zweifelsfall oder bei Problemen mit dem aushängen, lassen wie es ist, beim nächsten Reboot des Rechners regelt sich das von selbst.

== mach mal fsck irgendwas ==

'''Der Antworter will dir hier verständlich machen, dass das Fehlerbild eventuell auch auf einen Filesystem-Error hindeuten könnte, und möchte dir raten mal das Filesystem zu überprüfen und reparieren zu lassen.'''

Dieses ist ein etwas komplexeres Thema, da es dabei verschieden Szenarien geben kann, hier einige Ausführungen die dem Linuxneuling in den meisten Fällen weiterhelfen soll. ''(Wir beschränken uns hier im Speziellen auf den Defaultfall bei Suse und die ext2/ext3 Filesysteme, eventuelle anderen Linuxfilesysteme (Ausnahmen bestätigen die Regel) würden mit den vorgestellten Befehlen auch automatisch repariert, bei einigen Filesystemen gibt es auch speziellen Optionen auf die hier nicht eingegangen wird.)
''

Zuerst aber einmal. '''Wir prüfen und reparieren Filesysteme immer in dem Betriebssystem zu dem das Filesystemtypen passen.''' Also '''ext2, ext2, reiserfs''' usw von Linux aus und '''ntfs, vfat''' usw von Windows aus. Mit einem BMW fährt man bei bestimmten Problemen auch nicht in einen VW Werkstatt und alleine die Tatsache das man ein Filesystem lesen und beschreiben kann, bedeutet noch nicht, das man es auch wirklich richtig reparieren kann.

Linuxfilesysteme werden beim booten überprüft, aber nicht immer und jedes mal wirklich vollständig. das dauert sonst je nach Größe manchmal viele Minuten bis Stunden. Und nur ganz selten ist es wirklich notwendig, da andere Mechnismen das recht gut abfedern. Es ist also dennoch jederzeit auch mal möglich, das im Filesystem kleinere oder größere Strukturfehler enthalten sind, die recht seltsame Fehler produzieren können.

===Die einfachste Möglichkeit: alle beim booten automatisch prüfen lassen ===

als Root an einer Konsole anmelden, und folgenden Befehl eingeben.
touch /forcefsck
Danach den Rechner rebooten. Der Befehl legt eine leere Datei an, die den Rechner dazu bringt, beim nächten Booten alle Linuxfilesysteme die er automatisch prüfen soll, wirklich komplett zu überprüfen und automatisch zu reparieren. Das kann je nach Größe und Anzahl der Platten eine ganze Zeit dauern, den Fortschritt könnt ihr auf der Bootkonsole verfolgen.

===Alternativ:die Filesysteme von einem anderem Linux aus prüfen===

Dazu muss man die Platten,Partitionen und deren genaue Namen kennen die ein Linuxfilesystem beherrbergen und zu diesem System gehören.
mount | grep ext
zeigt zum Beispiel in aktuellem System alle derzeit aktiven ext2/ext3 Filesysteme, in der Ausgabe
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
die beiden Partitionen /dev/sda2 und /dev/sda3 währe in diesem Beispeil das, was wir uns merken müssten.
Danach zB von einer Live-CD oder ein anderes Linux auf diesem Rechner booten. Sicher stellen das diese Partitionen nicht gemountet sind. Dazu den Befehl '''mount''' absetzen und nachschauen, das diese "gemerkten" Partitionen nicht dabei sind. Sollten sie dennoch hier in der Ausgabe enthalten sein, müssten wir sie aushängen. 
Als root am System anmelden.
umount /dev/sda2
umount /dev/sda3
Beide Befehle sollten ohne irgendwelche Ausgaben durchlaufen. und die Partitionen hinterher mit mount nicht mehr sichtbar sein 
Danach können (ebenfalls nur als Root) die Filesysteme überprüft und repariert werden.
fsck -f -y /dev/sda2
fsck -f -y /dev/sda3
Die Ausgaben hier können insbesondere wenn Fehler im Filesystem repariert werden, recht lang werden. Diese Befehle bitte nicht vorzeitig abbrechen auch wenn sie etwas länger dauern. Ist etwas größeres zu reparieren sorgt die mitgegebenen Option '''-y''' dafür, das wir immer dafür sind und alle Reparaturvorschläge von '''fsck''' akzeptieren. (Alle andere Entscheidungen könnten eh nur absolute Spezialisten richtig treffen) Sind die Befehle durchgelaufen, kann dieses Linux beendet werden und das nomale Linux wieder gestartet werden.

===Der Ernstfall, Linux bleibt beim booten beim fsck stehen===

Nicht alle Fehler werden beim automatischen Prüfen der Filesysteme auch automatisch behoben. Bei schwerwiegenden Fehlern wird der Bootvorgang an dieser Stelle abgebrochen und der User aufgefordert den Filesystemcheck per Hand selbst anzustoßen. Nicht das Linux das nicht reparieren könnte, aber man wird eben aufgefordert hier bestimmte Aktionen abzunicken, das hinterher niemand sagen kann, Linux und der fsck ist schuld das jetzt meine Daten im Eimer sind ;-)
Diese Situation kann sowohl beim forcierten fsck (wie wir es oben vorgestellt haben), als auch bei irgend einem automatisch in regelmäßigen Abständen gestarteten kompletten Filesystemcheck einmal auftreten.

Wir müssen hier 2 Szenarien unterscheiden, entweder es ist das Rootfilesystem oder es ist ein anderes Filesystem als das Rootfilesystem, das man dazu naturlich das Passwort von root benötigt, sollte jetzt jedem klar sein.

==== fsck Fehler im Rootfilesystem====

Beim scheitern von fsck im Rootfilesystem erscheint kurz vor der Aufforderung der Anmeldung folgender Absatz
<pre>fsck failed. Please repair manually and reboot. The root
file system is currently mounted read-only. To remount it
read-write do:

bash# mount -n -o remount,rw /

Attention: Only CONTROL-D will reboot the system in this
maintanance mode. shutdown or reboot will not work.</pre>

Hier ist das Rootfilesystem noch readonly eingehängt. Bestimmte Befehle werden deshalb auch nicht oder nicht richtig funktionieren, desshalb auch der Hinweis auf den wichtigen Befehl zum eventuellen umhängen des Rootfilesystems zum "Read-Write". Aber wir brauchen eigentlich nur einen einzigen Befehl hier.
/sbin/fsck -f -y /
* die Option '''-f''' bedeutet wirklich kompletten filesystemcheck
* die Option '''-y''' bedeutet alle eventuellen Fragen automatisch mit "JA" beantworten
* die Option '''/''' : das ist das Rootfilesystem, (braucht hier nicht als /dev/... angegeben zu werden.)
Da das Filesystem hier an dieser Stelle jedoch schon readonly gemountet ist, erhalten wir eine Fehlermeldung wegen genau diesem Umstand. Das ist hier in diesem Fall relativ ungefährlich da ja sonst noch nichts weiter läuft, und wir müssen hier an dieser Stelle jetzt da durch, also soll er fsck auch durchführen, obwohl das Filesystem gemountet ist, anders geht es an dieser Stelle nicht.

Ist der Befehl durchgelaufen, dann mit '''"CONTROL-D"''' den Rechner rebooten. (''Achtung die Tastatur wird hier auf Englisch stehen, und viele andere Befehle nicht funktionieren, bzw müssen mit kopletten Path angegeben werden, damit sie überhaupt erst einmal gefunden werden.''

==== fsck Fehler jedoch nicht Rootfilesystem====

Wenn ein anders Filesystem als das Rootfilesystem betroffen ist, steht kurz vor der Anmeldeaufforderung folgender Text.
<pre>fsck failed for at least one filesystem (not /).
Please repair manually and reboot.
The root file system is is already mounted read-write.

Attention: Only CONTROL-D will reboot the system in this
maintanance mode. shutdown or reboot will not work.</pre>

Prinzipell gehen wir hier genauso vor, nur ist nicht immer sofort erkennbar welches andere Filesystem denn nun betroffen ist. Das gilt es erst zu ermitteln. Wenn außer Rootfilesystem nur noch /home zum System gehört, muss es dieses sein, sind jedoch mehrere da, dann müssen wird das ermitteln. Der Befehl mount hilft uns einen Überblick zu verschaffen was schon alles da ist. bzw was fehlt
/bin/mount
ist jetzt und mit dem Vergleich zur Datei '''/etc/fstab''' immer noch nicht klar, welches Filesystem nun das betreffende ist, versuchen wir einfach mal alle Filesysteme automatisch einzuhängen.
/bin/mount -a
Jetzt müsste eine Fehlermeldung kommen welches Filesystem sich nicht einhängen läßt, weil es einen fsck benötigt. Auf dieses Filesystem starten wir jetzt fsck. zB
/sbin/fsck -f -y /home
Das Filesystem kann entweder mit seinem Deviceknoten also zB '''/dev/sda4''' oder seinem Einhängepunkt zB '''/home''' angesprochen werden, eine Zuordnung nimmt Linux automatisch an Hand der Datei '''/etc/fstab''' vor. 
Prinzipell ist es auch möglich das hier mehrere Filesysteme betroffen sind oder nicht eingehängt werden können, weil das darunterliegende betroffen ist. Wir können mit '''/bin/mount -a''' jedoch solange probieren bis hier alle Filesysteme eingehängt sind und eventuell auch noch weitere noch reparieren. Danach wieder mit '''"CONTROL-D"''' den Rechner rebooten.

== mach mal sax2 -(Zeichen) ==

'''Nach der Installation, nach einem Hardwareumbau, nach bestimmten Updates oder einfach nachdem ihr zuviel an der Konfiguration herumgespielt habt, kann es sein, das eure Grafische Oberfläche nicht mehr startet. '''[http://manpages.unixforum.co.uk/man-pages/linux/opensuse-10.2/1/SaX2-man-page.html sax2]''' ist das Programm mit dem Grafikkarte, Bildschirm, Maus und Tastatur für den X-Server bei Suse grundkonfiguriert wird.'''

Der X-Server ist das Programm das erst einmal überhaupt eine leere grafische Oberfläche zur Verfügung stellt, mit der zB dann der Windowsmanager seine Fenster auch anzeigen kann. 
Das Programm '''sax2''', wird euch sicherlich schon bei der Installation beim Einrichten der Grafikkarte begegnet sein. Auch aus der Grafischen Oberfläche ist es erreichbar "'''Yast -> Hardware > Grafikkarte und Monitor'''" das nützt aber nichts, wenn die Grafische Oberfläche gar nicht erst starten will. Also muss das auch aus der Konsole heraus gehen. Dazu benötigen wir also eine Konsole wie [[Hilfe zu Antworten aus dem Forum#gib mal folgendes ein|oben]] beschrieben. Des weiteren brauchen wird dort ein [[Hilfe zu Antworten aus dem Forum#als root folgendes eingeben|Login als root]] und nicht zuletzt müssen wir sicher sein das kein X-Server mehr aktiv ist, am besten also noch in den [[Hilfe zu Antworten aus dem Forum#mach mal init 3 |Runlevel 3]] wechseln

Damit ist der Rechner jetzt vorbereitet um den '''sax2''' Befehl erfolgreich ausführen zu können. Der Aufruf ist einfach
sax2
in vielen Fällen werdet ihr vom Antworter jedoch noch zusätzlichen Optionen bekommen haben, dann diese einfach so eingeben wie sie dort stehen. zB
sax2 -r -i -l
Was jetzt passiert ist von den Optionen abhängig, in den meisten Fällen wird sich ein grafisches Fenster öffnen das dem der Grafikkartenkonfiguration beim Installieren nicht ganz unähnlich ist. Dann dort eventuell noch Einstellungen tätigen und erst speichern und beenden , wenn der Funktionstest wirklich richtig funktioniert hat. Es ist aber auch möglich, das beim sax2 Befehl nur eine neue Konfigurationsdatei geschrieben wird, und sonst nichts aufregendes passiert.

Ist das vollbracht, dann kann die Grafische Oberfläche jetzt wieder getestet werden. Dazu einfach wieder mit
init 5
in den Runlevel 5 wechseln oder den Rechner mit
init 6
rebooten und damit mit der hoffentlich jetzt funktionieren Konfiguration die Grafik wieder normal zu starten.

==Notes==
<references />

[[Linupedia:Hilfe|Zurück zur Hilfe Übersicht]]
[[Category:LinuxClubWiki Hilfe]]

Alte Hardware

2012-10-04T21:23:31Z

Josef-wien: LXDE ergänzt

Da im Forum immer wieder die Frage auftaucht, "welches [[Linux]]" man auf einem '''alten Rechner''' mit betagter und langsamer Hardware installieren soll, folgen hier ein paar Gedanken zu diesem Problem:

== Was zeichnet einen solchen alten Rechner aus? ==
Wenig Prozessorleistung, wenig RAM, eine minderbemittelte Grafikkarte (auch ohne 3D) und eine kleine Festplatte. Daraus folgt, dass alles was viel Prozessor, RAM, Platz oder Grafikleistung benötigt auf alter Hardware entweder nicht, oder nur schleppend und spaßfrei läuft.
Auf einem Rechner mit 400Mhz und 128MB RAM kann aber trotzdem [[Linux]] ganz flott laufen.

== Welches Linux für einen solchen Rechner ==
Es gibt nur ein [[Linux]] - und das ist auch das richtige. Die Frage müsste heissen, welche [[Linux Distributionen|Distribution]] ist besonders dafür geeignet?
* [http://vectorlinux.com/ Vector Linux]
* [http://www.damnsmalllinux.org/ Damn Small Linux]
* [http://www.puppylinux.org/ Puppy Linux]
* [http://www.zenwalk.org/ Zenwalk Linux]
* [http://delilinux.de/ DeLi Linux]
* [http://lubuntu.net/ Lubuntu]

== Warum es eigentlich egal ist, welche Distribution man nutzt ==
Wichtig bei der Installation von Linux auf schwacher [[Hardware]] ist, dass ressourcenfressende Software außen vor bleibt und unnötige Dienste deaktiviert bleiben.
Hier fallen vor allem die grafischen Oberflächen ins Gewicht. Kleine und schlanke Oberflächen sind z.B. [[OpenBox]], [[FluxBox]], [[fvwm]], LXDE oder [[xfce]]. Nicht verwenden sollte man [[KDE]] oder [[gnome]]. Auch [[OpenOffice]] oder [[seamonkey]] können ordentlich Ressourcen fressen. Alle großen [[Linux Distributionen|Distributionen]] haben ein sehr breites Softwareangebot und es ist sehr wohl möglich auch diese auf einem alten Rechner einzusetzen, man muss genauso wie bei allen Distributionen die passende Software auswählen.

== Weitere Programmempfehlungen ==
* Mailclient: [[claws-mail]]
* Textverarbeitung: [[abiword]], [[lyx]] oder gleich [[LaTeX]]
* Tabellenkalkulation: [[gnumeric]]
* Media-Player: [[audacious]], [[vlc]]

== Quellenangaben und weiterführende Links ==
* [http://www.linux-user.de/ausgabe/2007/10/034-distros/index.html Artikel der Zeitschrift "LinuxUser" - "Schlanker Unterbau - Linux für betagte Rechner"]

----
[[Allgemeines|Zurück zu Allgemeines]]

[[Kategorie:Allgemeines]]

Videoconverterscript

2012-06-14T10:07:43Z

Josef-wien: Zweiten Rückwärts-Schrägstrich ergänzt und Formalfehler-Meldungen umschifft (im Konsolfenster "PSP-Thumb Converting" sind ffmpeg-Fehler vorhanden).

Hier ein kleines Script zum automatischen konvertieren bekannter Videoformate in DVD, VCD, SVCD und PSP konforme Mpeg-Dateien:
=Allgemeine Version=
Voraussetzung: ffmpeg und mencoder(im mplayer Paket enthalten) müssen installiert sein, für die Ausgangsdaten eventuell weitere benötigte Codecs sollten ebenso installiert sein.

Benötigter Parameter: Der Name der zu konvertierenden Datei bzw. des Ausgangsmediums.
Beispiel:
converterscript.sh ./meinfilm.avi

----

'''To-Do Liste:'''

* Overrideoption für die Settings über die Kommandozeile einbauen
* Ncurses oder grafische Oberfläche dazu passend erstellen oder einbauen
* Weitere Formate einbauen
* Optionale Einstellung für den Konsolentyp/Terminaltyp einbauen (bisher nur mit der KDE-Konsole laufend)

----

{|-
|'''Changelog:'''
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&oldid=12609 v0.0.2-ccj1]''
|Leerzeichen in Dateinamen akzeptieren, if[]-Tests und Struktur vereinfachen
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&direction=prev&oldid=12606 v0.0.2]''
|Zielformateauswahl verbessert und Prüfung auf Existenz der Zielverzeichnise eingebaut, von parallel laufender Multi-Konsolenversion auf lineare Version mit nur einem weiteren Konsolenfenster umgebaut
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&direction=next&oldid=5845 v.0.0.1b]''
|Grundlegende Pfadstruktur der Zielpfade verbessert
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&oldid=2970 v.0.0.1]''
|Anfangsversion des Converterscripts
|-
|}
----
converterscript.sh
<pre>
#!/bin/sh
# Conversionscript for converting Videofiles to Widescreen+Fullscreen/ PAL+NTSC DVD, PAL+NTSC VCD/SVCD/XVCD, PSP Fileformat with Help of mencoder and ffmpeg
# V. 0.0.2-ccj1
#
# ccj-Fork by LC-User jengelh with permission of Mainline Creator
# Mainline (c) by Tom Meierjürgen tomcatmj@web.de
# Licence: Creative Commons - attribution - non-commercial - sharealike
#
# Basic settings
#
#
# Mediatype ALL, DVD, VCD or PSP
#
MEDIA=ALL
#
# TV-Standards
# Choose PAL, NTSC or ALL
STANDARD=ALL
#
# Fullscreen or Widescreen or both (DVD only) (FULL, WIDE, BOTH)
VIEW=BOTH
#
# Choose VCD, SVCD, XVCD or ALL
#
CDTYPE=ALL
#
# Targetdirectories, change values to your needs
BASE="~/converted";
PSP="$BASE/PSP";
FULLDVD="$BASE/DVD/FULLSCREEN";
WIDEDVD="$BASE/DVD/WIDESCREEN";
VCD="$BASE/VCD";
XVCD="$BASE/XVCD";
SVCD="$BASE/SVCD";
#
# Initializing and conversions
#
# Check if basic targetdirectory exists
#
mkdir -p "$BASE";

basename1="${1##*/}";
#
# DVD initial targetdirectory existencecheck
#
# Check if DVD-Targetdirectories exist
#
# FFMpeg Fullscreen DVD
#
if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/ffmpeg/PAL";
echo "Starting Fullscreen PAL-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Fullscreen PAL-DVD Converting..." -e ffmpeg -i "$1" -target pal-dvd -aspect 4:3 "$FULLDVD/ffmpeg/PAL/$basename1.mpg";
echo "Fullscreen PAL-DVD conversion with ffmpeg finished.";
else
echo "No Fullscreen PAL-DVD conversion with encodertype ffmpeg selected";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/ffmpeg/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Fullscreen NTSC-DVD Converting..." -e ffmpeg -i "$1" -target ntsc-dvd -aspect 4:3 "$FULLDVD/ffmpeg/NTSC/$basename1.mpg";
echo "Fullscreen NTSC-DVD conversion with ffmpeg finished.";
else
echo "No Fullscreen NTSC-DVD conversion with encodertype ffmpeg selected.";
fi

#
# FFMpeg Widescreen DVD
#
if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/ffmpeg/PAL";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Widescreen PAL-DVD Converting..." -e ffmpeg -i "$1" -target pal-dvd -aspect 16:9 "$WIDEDVD/ffmpeg/PAL/$basename1.mpg";
echo "Widescreen PAL-DVD with ffmpeg finished.";
else
echo "No Widescreen PAL-DVD conversion with encodertype ffmpeg selected.\n";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/ffmpeg/NTSC";
echo "Starting Widescreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Widescreen NTSC-DVD Converting..." -e ffmpeg -i "$1" -target ntsc-dvd -aspect 16:9 "$WIDEDVD/ffmpeg/NTSC/$basename1.mpg";
echo "Widescreen NTSC-DVD conversion with ffmpeg finished.";
else
echo "No Widescreen NTSC-DVD conversion with encodertype ffmpeg selected.";
fi

#
# Mencoder Fullscreen DVD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/mencoder/PAL";
echo "Starting Fullscreen PAL-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Fullscreen PAL-DVD Converting..." -e time mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=352:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:abitrate=192:aspect=4/3 -ofps 25 -o "$FULLDVD/mencoder/PAL/$basename1.mpg" "$1";
echo "Fullscreen PAL-DVD conversion with mencoder finished.";
else
echo "No Fullscreen PAL-DVD conversion with encodertype mencoder selected.";
fi

if [ $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/mencoder/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Fullscreen NTSC-DVD Converting..." -e time mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=352:480,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:abitrate=192:aspect=4/3 -ofps 30000/1001 -o "$FULLDVD/mencoder/NTSC/$basename1.mpg" "$1";
echo "Fullscreen NTSC-DVD conversion with mencoder finished.";
else
echo "No Fullscreen NTSC-DVD conversion with encodertype mencoder selected.";
fi

#
# Mencoder Widescreen DVD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/mencoder/PAL";
echo "Starting Widescreen PAL-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Widescreen PAL-DVD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:abitrate=192:aspect=16/9 -ofps 25 -o "$WIDEDVD/mencoder/PAL/$basename1.mpg" "$1";
echo "Widescreen PAL-DVD conversion finished.";
else
echo "No Widescreen PAL-DVD conversion with encodertype mencoder selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/mencoder/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Widescreen NTSC-DVD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:abitrate=192:aspect=16/9 -ofps 30000/1001 -o "$WIDEDVD/mencoder/NTSC/$basename1.mpg" "$1";
echo "Widescreen NTSC-DVD conversion finished.";
else
echo "No Widescreen NTSC-DVD conversion with encodertype mencoder selected.";
fi

#
# VCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == VCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$VCD/ffmpeg/PAL";
echo "Starting PAL-VCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG PAL-VCD Converting..." -e ffmpeg -i "$1" -target pal-vcd "$VCD/ffmpeg/PAL/$basename1.mpg";
echo "PAL-VCD conversion finished.";
else
echo "No PAL-VCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE" == VCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$VCD/ffmpeg/NTSC";
echo "Starting NTSC-VCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG NTSC-VCD Converting..." -e time ffmpeg -i "$1" -target ntsc-vcd "$VCD/ffmpeg/NTSC/$basename1.mpg";
echo "NTSC-VCD conversion finished.";
else
echo "No NTSC-VCD conversion selected.";
fi

#
# SVCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == SVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$SVCD/ffmpeg/PAL";
echo "Starting PAL-SVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG PAL-SVCD Converting..." -e ffmpeg -i "$1" -target pal-svcd "$SVCD/ffmpeg/PAL/$basename1.mpg";
echo "PAL-SVCD conversion finished.";
else
echo "No PAL-SVCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE" == SVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$SVCD/ffmpeg/NTSC";
echo "Starting NTSC-SVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG NTSC-SVCD Converting..." -e ffmpeg -i "$1" -target ntsc-svcd "$SVCD/ffmpeg/NTSC/$basename1.mpg";
echo "NTSC-SVCD conversion finished.";
else
echo "No NTSC-SVCD conversion selected.";
fi

#
# XVCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == XVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$XVCD/mencoder/PAL";
echo "Starting PAL-XVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER PAL XVCD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 25 -o "$XVCD/mencoder/PAL/$basename1.mpg" "$1";
echo "PAL-XVCD conversion finished.";
else
echo "No PAL-XVCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE" == XVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$XVCD/mencoder/NTSC";
echo "Starting NTSC-XVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER NTSC XVCD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 30000/1001 -o "$XVCD/mencoder/NTSC/$basename1.mpg" "$1";
echo "NTSC-XVCD conversion finished.";
else
echo "No NTSC-XVCD conversion selected.";
fi

#
# PSP
#

if [[ "$MEDIA" == ALL || "$MEDIA" == PSP ]]; then
mkdir -p "$PSP";
echo "PSP conversion started...";
time konsole --caption "Converterscript v.0.0.2 - Converting for Sony PlayStationPortable..." -e ffmpeg -i "$1" -f psp -r 14.985 -s 320x240 -b 768 -ar 24000 -ab 32 "$PSP/$basename1.MP4";
echo "Creating thumbnail graphics...";
time konsole --noclose --caption "Converterscript v.0.0.2 - PSP-Thumb Converting..." -e ffmpeg -y -i "$1" -f ljpeg -ss 5 -vframes 1 -s 160x120 -an "$PSP/$basename1.THM";
echo "PSP Conversion finished.";
else
echo "PSP-Conversion not selected.";
fi

#
# Special
#

if [ "$MEDIA" == ALL -o "$MEDIA" == "Special" ]; then
mkdir -p "$PSP";
echo "For future special devices... not available for now, so PSP conversion started...";
time konsole --caption "Converterscript v.0.0.2 - Converting for Sony PlayStationPortable..." -e ffmpeg -i "$1" -f psp -r 14.985 -s 320x240 -b 768 -ar 24000 -ab 32 "$PSP/$basename1.MP4";
echo "Creating thumbnail graphics...";
time konsole --noclose --caption "PSP-Thumb Converting..." -e ffmpeg -y -i "$1" -f ljpeg -ss 5 -vframes 1 -s 160x120 -an "$PSP/$basename1.THM";
echo "PSP Conversion finished.";
else
echo "PSP-Conversion not selected.";
fi

echo "Conversions finished.";
</pre>

--[[Benutzer:TomcatMJ|TomcatMJ]] 10:27, 14. Mär 2007 (CET)

=GP2X Version=
{{:Videoconverterscript/GP2X}}
----
[[Multimedia | Zurück zur Multimediaübersicht]] 
[[Shellscripte | Zurück zur Shellscripteübersicht]] 
[[Videokonvertierung und DVD oder SVCD erstellen | Zurück zu "Videokonvertierung und DVD oder SVCD erstellen"]]

[[Category:Scripte]]
[[Category:Multimedia]]

Videoconverterscript

2012-06-11T20:32:24Z

Josef-wien: Der fehlende Rückwärts-Schrägstrich in Skript-Zeile 59, Spalte 6, wurde ergänzt.

Hier ein kleines Script zum automatischen konvertieren bekannter Videoformate in DVD, VCD, SVCD und PSP konforme Mpeg-Dateien:
=Allgemeine Version=
Voraussetzung: ffmpeg und mencoder(im mplayer Paket enthalten) müssen installiert sein, für die Ausgangsdaten eventuell weitere benötigte Codecs sollten ebenso installiert sein.

Benötigter Parameter: Der Name der zu konvertierenden Datei bzw. des Ausgangsmediums.
Beispiel:
converterscript.sh ./meinfilm.avi

----

'''To-Do Liste:'''

* Overrideoption für die Settings über die Kommandozeile einbauen
* Ncurses oder grafische Oberfläche dazu passend erstellen oder einbauen
* Weitere Formate einbauen
* Optionale Einstellung für den Konsolentyp/Terminaltyp einbauen (bisher nur mit der KDE-Konsole laufend)

----

{|-
|'''Changelog:'''
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&oldid=12609 v0.0.2-ccj1]''
|Leerzeichen in Dateinamen akzeptieren, if[]-Tests und Struktur vereinfachen
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&direction=prev&oldid=12606 v0.0.2]''
|Zielformateauswahl verbessert und Prüfung auf Existenz der Zielverzeichnise eingebaut, von parallel laufender Multi-Konsolenversion auf lineare Version mit nur einem weiteren Konsolenfenster umgebaut
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&direction=next&oldid=5845 v.0.0.1b]''
|Grundlegende Pfadstruktur der Zielpfade verbessert
|-
|''[http://www.linux-club.de/wiki/index.php?title=Videoconverterscript&oldid=2970 v.0.0.1]''
|Anfangsversion des Converterscripts
|-
|}
----
converterscript.sh
<pre>
#!/bin/sh
# Conversionscript for converting Videofiles to Widescreen+Fullscreen/ PAL+NTSC DVD, PAL+NTSC VCD/SVCD/XVCD, PSP Fileformat with Help of mencoder and ffmpeg
# V. 0.0.2-ccj1
#
# ccj-Fork by LC-User jengelh with permission of Mainline Creator
# Mainline (c) by Tom Meierjürgen tomcatmj@web.de
# Licence: Creative Commons - attribution - non-commercial - sharealike
#
# Basic settings
#
#
# Mediatype ALL, DVD, VCD or PSP
#
MEDIA=ALL
#
# TV-Standards
# Choose PAL, NTSC or ALL
STANDARD=ALL
#
# Fullscreen or Widescreen or both (DVD only) (FULL, WIDE, BOTH)
VIEW=BOTH
#
# Choose VCD, SVCD, XVCD or ALL
#
CDTYPE=ALL
#
# Targetdirectories, change values to your needs
BASE="~/converted";
PSP="$BASE/PSP";
FULLDVD="$BASE/DVD/FULLSCREEN";
WIDEDVD="$BASE/DVD/WIDESCREEN";
VCD="$BASE/VCD";
XVCD="$BASE/XVCD";
SVCD="$BASE/SVCD";
#
# Initializing and conversions
#
# Check if basic targetdirectory exists
#
mkdir -p "$BASE";

basename1="${1##*/}";
#
# DVD initial targetdirectory existencecheck
#
# Check if DVD-Targetdirectories exist
#
# FFMpeg Fullscreen DVD
#
if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/ffmpeg/PAL";
echo "Starting Fullscreen PAL-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Fullscreen PAL-DVD Converting..." -e ffmpeg -i "$1" -target pal-dvd -aspect 4:3 "$FULLDVD/ffmpeg/PAL/$basename1.mpg";
echo "Fullscreen PAL-DVD conversion with ffmpeg finished.";
else
echo "No Fullscreen PAL-DVD conversion with encodertype ffmpeg selected";
fi

if [ $ "$MEDIA" == ALL || "$MEDIA" == DVD ) && \( "$STANDARD" == ALL -o "$STANDARD" == NTSC $ && $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/ffmpeg/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Fullscreen NTSC-DVD Converting..." -e ffmpeg -i "$1" -target ntsc-dvd -aspect 4:3 "$FULLDVD/ffmpeg/NTSC/$basename1.mpg";
echo "Fullscreen NTSC-DVD conversion with ffmpeg finished.";
else
echo "No Fullscreen NTSC-DVD conversion with encodertype ffmpeg selected.";
fi

#
# FFMpeg Widescreen DVD
#
if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/ffmpeg/PAL";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Widescreen PAL-DVD Converting..." -e ffmpeg -i "$1" -target pal-dvd -aspect 16:9 "$WIDEDVD/ffmpeg/PAL/$basename1.mpg";
echo "Widescreen PAL-DVD with ffmpeg finished.";
else
echo "No Widescreen PAL-DVD conversion with encodertype ffmpeg selected.\n";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/ffmpeg/NTSC";
echo "Starting Widescreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG Widescreen NTSC-DVD Converting..." -e ffmpeg -i "$1" -target ntsc-dvd -aspect 16:9 "$WIDEDVD/ffmpeg/NTSC/$basename1.mpg";
echo "Widescreen NTSC-DVD conversion with ffmpeg finished.";
else
echo "No Widescreen NTSC-DVD conversion with encodertype ffmpeg selected.";
fi

#
# Mencoder Fullscreen DVD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/mencoder/PAL";
echo "Starting Fullscreen PAL-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Fullscreen PAL-DVD Converting..." -e time mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=352:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:abitrate=192:aspect=4/3 -ofps 25 -o "$FULLDVD/mencoder/PAL/$basename1.mpg" "$1";
echo "Fullscreen PAL-DVD conversion with mencoder finished.";
else
echo "No Fullscreen PAL-DVD conversion with encodertype mencoder selected.";
fi

if [ $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == FULL -o "$VIEW" == BOTH $ ]; then
mkdir -p "$FULLDVD/mencoder/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Fullscreen NTSC-DVD Converting..." -e time mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=352:480,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:abitrate=192:aspect=4/3 -ofps 30000/1001 -o "$FULLDVD/mencoder/NTSC/$basename1.mpg" "$1";
echo "Fullscreen NTSC-DVD conversion with mencoder finished.";
else
echo "No Fullscreen NTSC-DVD conversion with encodertype mencoder selected.";
fi

#
# Mencoder Widescreen DVD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/mencoder/PAL";
echo "Starting Widescreen PAL-DVD conversion with mencoder...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Widescreen PAL-DVD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:abitrate=192:aspect=16/9 -ofps 25 -o "$WIDEDVD/mencoder/PAL/$basename1.mpg" "$1";
echo "Widescreen PAL-DVD conversion finished.";
else
echo "No Widescreen PAL-DVD conversion with encodertype mencoder selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == DVD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$VIEW" == WIDE -o "$VIEW" == BOTH $ ]; then
mkdir -p "$WIDEDVD/mencoder/NTSC";
echo "Starting Fullscreen NTSC-DVD conversion with ffmpeg...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER Widescreen NTSC-DVD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:abitrate=192:aspect=16/9 -ofps 30000/1001 -o "$WIDEDVD/mencoder/NTSC/$basename1.mpg" "$1";
echo "Widescreen NTSC-DVD conversion finished.";
else
echo "No Widescreen NTSC-DVD conversion with encodertype mencoder selected.";
fi

#
# VCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == VCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$VCD/ffmpeg/PAL";
echo "Starting PAL-VCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG PAL-VCD Converting..." -e ffmpeg -i "$1" -target pal-vcd "$VCD/ffmpeg/PAL/$basename1.mpg";
echo "PAL-VCD conversion finished.";
else
echo "No PAL-VCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE" == VCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$VCD/ffmpeg/NTSC";
echo "Starting NTSC-VCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG NTSC-VCD Converting..." -e time ffmpeg -i "$1" -target ntsc-vcd "$VCD/ffmpeg/NTSC/$basename1.mpg";
echo "NTSC-VCD conversion finished.";
else
echo "No NTSC-VCD conversion selected.";
fi

#
# SVCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD -a \( "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == SVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$SVCD/ffmpeg/PAL";
echo "Starting PAL-SVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG PAL-SVCD Converting..." -e ffmpeg -i "$1" -target pal-svcd "$SVCD/ffmpeg/PAL/$basename1.mpg";
echo "PAL-SVCD conversion finished.";
else
echo "No PAL-SVCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE == SVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$SVCD/ffmpeg/NTSC";
echo "Starting NTSC-SVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - FFMPEG NTSC-SVCD Converting..." -e ffmpeg -i "$1" -target ntsc-svcd "$SVCD/ffmpeg/NTSC/$basename1.mpg";
echo "NTSC-SVCD conversion finished.";
else
echo "No NTSC-SVCD conversion selected.";
fi

#
# XVCD
#

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == PAL $ -a $ "$CDTYPE" == XVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$XVCD/mencoder/PAL";
echo "Starting PAL-XVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER PAL XVCD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 25 -o "$XVCD/mencoder/PAL/$basename1.mpg" "$1";
echo "PAL-XVCD conversion finished.";
else
echo "No PAL-XVCD conversion selected.";
fi

if [ $ "$MEDIA" == ALL -o "$MEDIA" == VCD $ -a $ "$STANDARD" == ALL -o "$STANDARD" == NTSC $ -a $ "$CDTYPE" == XVCD -o "$CDTYPE" == ALL $ ]; then
mkdir -p "$XVCD/mencoder/NTSC";
echo "Starting NTSC-XVCD conversion...";
time konsole --caption "Converterscript v.0.0.2 - MENCODER NTSC XVCD Converting..." -e mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 30000/1001 -o "$XVCD/mencoder/NTSC/$basename1.mpg" "$1";
echo "NTSC-XVCD conversion finished.";
else
echo "No NTSC-XVCD conversion selected.";
fi

#
# PSP
#

if [ "$MEDIA" == ALL || "$MEDIA" == PSP ]; then
mkdir -p "$PSP";
echo "PSP conversion started...";
time konsole --caption "Converterscript v.0.0.2 - Converting for Sony PlayStationPortable..." -e ffmpeg -i "$1" -f psp -r 14.985 -s 320x240 -b 768 -ar 24000 -ab 32 "$PSP/$basename1.MP4";
echo "Creating thumbnail graphics...";
time konsole --noclose --caption "Converterscript v.0.0.2 - PSP-Thumb Converting..." -e ffmpeg -y -i "$1" -f ljpeg -ss 5 -vframes 1 -s 160x120 -an "$PSP/$basename1.THM";
echo "PSP Conversion finished.";
else
echo "PSP-Conversion not selected.";
fi

#
# Special
#

if [ "$MEDIA" == ALL -o "$MEDIA == "Special" ]; then
mkdir -p "$PSP";
echo "For future special devices... not available for now, so PSP conversion started...";
time konsole --caption "Converterscript v.0.0.2 - Converting for Sony PlayStationPortable..." -e ffmpeg -i "$1" -f psp -r 14.985 -s 320x240 -b 768 -ar 24000 -ab 32 "$PSP/$basename1.MP4";
echo "Creating thumbnail graphics...";
time konsole --noclose --caption "PSP-Thumb Converting..." -e ffmpeg -y -i "$1" -f ljpeg -ss 5 -vframes 1 -s 160x120 -an "$PSP/$basename1.THM";
echo "PSP Conversion finished.";
else
echo "PSP-Conversion not selected.";
fi

echo "Conversions finished.";
</pre>

--[[Benutzer:TomcatMJ|TomcatMJ]] 10:27, 14. Mär 2007 (CET)

=GP2X Version=
{{:Videoconverterscript/GP2X}}
----
[[Multimedia | Zurück zur Multimediaübersicht]] 
[[Shellscripte | Zurück zur Shellscripteübersicht]] 
[[Videokonvertierung und DVD oder SVCD erstellen | Zurück zu "Videokonvertierung und DVD oder SVCD erstellen"]]

[[Category:Scripte]]
[[Category:Multimedia]]

Zwei Kernel parallel installieren

2012-05-25T20:03:22Z

Josef-wien: Box Test: 12.1 ergänzt

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1, 11.3, 11.4, 12.1
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln. D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

Mit Ausnahme von openSUSE 11.1 besteht der kompilierte Kernel aus einer *.rpm-Datei. Bei openSUSE 11.1 sind es mit Ausnahme des Vanilla-Kernel drei *.rpm-Dateien (kernel-xxx, kernel-xxx-base und kernel-xxx-extra, xxx steht für den Kernel-Typ, z.B. default), die als Einheit betrachtet werden sollen; die Datei kernel-xxx-extra sollte nur dann weggelassen werden, wenn man ganz sicher ist, diese Module nicht zu benötigen. Ab openSUSE 11.2 ist das Paket kernel-xxx-base nur eine relativ kleine Teilmenge von kernel-xxx und für den normalen Anwender nicht zielführend.

== Bevorzugte Variante ==

Seit einigen openSUSE-Versionen ist es möglich, mit zypper (und damit auch mit YaST) mehrere Kernel desselben Typs zu installieren. Dazu muss in der Datei /etc/zypp/zypp.conf die Zeile
multiversion = provides:multiversion(kernel)
aktiviert werden.

== Früher notwendige Varianten ==

=== Erste Variante ===

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

=== Zweite Variante ===

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

Unter openSUSE 11.1 ist diese Variante aufgrund von Abhängigkeitsproblem leider nicht mehr möglich.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Ab openSUSE 11.1 (und möglicherweise früher) genügt es jetzt im Normalfall zu überprüfen, ob der Kernel in <code>/boot/grub/menu.lst</code> richtig eingetragen wurde. Nur bei älteren Versionen ist es wichtig zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>. Neuere openSUSE-Versionen schreiben nämlich nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>. Bei Bedarf muss darum zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

Winterliche Pinguine im Bootmenue von GRUB

2011-12-06T22:24:44Z

Josef-wien: Hinweis auf Funktionstasten

__FORCETOC__

Seit [[OpenSUSE]] 10.2 (Dezember 2006) erscheint um den Jahreswechsel manchmal ein Bootmenü mit winterlichem Hintergrund und wandernden Pinguinen (mit einigen Funktionstasten können übrigens ein paar Effekte ausgelöst werden). Die Häufigkeit des Erscheinens läßt sich individuell festlegen, die Befehle müssen als '''root''' ausgeführt werden.

Zur Sicherheit ist eine Kopie des grafischen Bootmenüs anzulegen:
cp /boot/message /boot/message.original

Um die winterlichen Pinguine das ganze Jahr über zu sehen, ist der Befehl
gfxboot --change-config base::penguin=100
auszuführen. Aber auch andere Werte haben ihre Bedeutung:
-1 Automatik (Standardeinstellung)
0 die winterlichen Pinguine erscheinen nie
1-99 je höher die Zahl, desto häufiger erscheinen die winterlichen Pinguine
Mit einer neuen [[OpenSUSE]]-''release'' wird die Datei ''/boot/message'' durch die neue Version überschrieben.

'''Fortgeschrittene Anwender''' können mit
cp /boot/message /boot/message-winter
ihre eigene Datei erzeugen, mit
gfxboot --archive /boot/message-winter --change-config base::penguin=100
anpassen und dann in ''/boot/grub/menu.lst'' eintragen.

Die Datei ''/boot/message'' ist ein CPIO-Archiv. Wie die darin enthaltene Konfigurationsdatei ''gfxboot.cfg'' angesehen bzw. extrahiert werden kann, und welche Möglichkeiten sonst noch bestehen, kann in der ''manpage'' von ''gfxboot'' nachgelesen werden.

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

Winterliche Pinguine im Bootmenue von GRUB

2011-11-30T17:21:08Z

Josef-wien:

__FORCETOC__

Seit [[OpenSUSE]] 10.2 (Dezember 2006) erscheint um den Jahreswechsel manchmal ein Bootmenü mit winterlichem Hintergrund und wandernden Pinguinen. Die Häufigkeit des Erscheinens läßt sich individuell festlegen, die Befehle müssen als '''root''' ausgeführt werden.

Zur Sicherheit ist eine Kopie des grafischen Bootmenüs anzulegen:
cp /boot/message /boot/message.original

Um die winterlichen Pinguine das ganze Jahr über zu sehen, ist der Befehl
gfxboot --change-config base::penguin=100
auszuführen. Aber auch andere Werte haben ihre Bedeutung:
-1 Automatik (Standardeinstellung)
0 die winterlichen Pinguine erscheinen nie
1-99 je höher die Zahl, desto häufiger erscheinen die winterlichen Pinguine
Mit einer neuen [[OpenSUSE]]-''release'' wird die Datei ''/boot/message'' durch die neue Version überschrieben.

'''Fortgeschrittene Anwender''' können mit
cp /boot/message /boot/message-winter
ihre eigene Datei erzeugen, mit
gfxboot --archive /boot/message-winter --change-config base::penguin=100
anpassen und dann in ''/boot/grub/menu.lst'' eintragen.

Die Datei ''/boot/message'' ist ein CPIO-Archiv. Wie die darin enthaltene Konfigurationsdatei ''gfxboot.cfg'' angesehen bzw. extrahiert werden kann, und welche Möglichkeiten sonst noch bestehen, kann in der ''manpage'' von ''gfxboot'' nachgelesen werden.

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

Winterliche Pinguine im Bootmenue von GRUB

2011-11-30T17:16:11Z

Josef-wien: Neuerstellung

Bootmanager

2011-11-30T16:33:31Z

Josef-wien: Neuer Eintrag: Winterliche Pinguine im Bootmenü von GRUB

== Bootloader ==
* [[GRUB]]
** [[GRUB wiederherstellen]]
** [[von Grub direkt auf CD-Boot umschwenken]]
** [[Grub-Install via "chroot" und Knoppix]]
** [[Grub, Raid1 Ausfallsicherheit]]
** [[Grub ERROR]]
** [[SuSE_und_Grub]] Zusammenspiel und Probleme - Yast-Bootloaderkonfiguration und Grub
** [[Linux booten via Grub-Shell]]
** [[Beim reboot das zu startende Betriebssystem auswählen]]
** [[GRUB Musterkonfigurationen]]
* [[o:SDB:Windows von der zweiten Festplatte booten]]
* [[o:SDB:Mehrere Windows-Installationen von einer Festplatte booten]]
* [[o:SDB:Linux mit Hilfe des Bootmanagers von Windows NT/2000/XP booten]]
* [[o:SDB:Passwort setzen für den Bootmanager GRUB]]
* [[o:SDB:Per GRUB über Netzwerk booten]]
* [http://www.linux-user.de/ausgabe/2007/04/030-vista-dualboot/index.html Vista-Bootloader für Linux einrichten]
* [[LILO]]
* [[Lilo wieder herstellen]] Den Bootloader LILO mit Hilfe einer Live-CD wiederherstellen.
* [[Installationsbootloader]] - Bootloader mit Schwerpunkt Systeminstallation. Diverse Bootloader, deren Schwerpunkt die Betriebssysteminstallation ist, die jedoch auch für Rescuesysteme, Servicetools und generellem Systemstart genutzt werden können(auch um über das Netzwerk zu booten).

== Verschiedenes ==
* [[Linkliste#FAQ_Kernel-_.2F_Bootparameter|FAQ Kernel/Bootparameter]] - Linkliste
* [[Winterliche Pinguine im Bootmenü von GRUB]]
* [[Splash Screen]] - Erstellen eines Splash Screens
* [[openSUSE automatisch herunterfahren lassen]]
* [[ReiserFS]]
* [[Disk Quota]] - Disk Quota auf Filesystemen einrichten
* [[Bootverzögerungen durch fsck]] - automatischen Filesystemcheck bei ext3 optimieren
* [[Windows auf Linux-PC installieren]] - Setup-Menü der Windows-Install-CD erscheint nicht

== Quellen und weiterführende Links ==

=== Artikel aus der SDB zu SuSE 9.3 ===

* [[o:SDB:Installation bleibt stehen oder findet keine Festplatten|Installation bleibt stehen oder findet keine Festplatten]]
* [[o:SDB:Nach Update von 9.2 auf 9.3 wird als Loginmanager XDM verwendet|Nach Update von 9.2 auf 9.3 wird als Loginmanager XDM verwendet]]
* [[o:SDB:Klassisch mounten statt subfs|Klassisch mounten statt subfs]]
* [[o:SDB:Mounten zu festen Mountpoints|Mounten zu festen Mountpoints]]

----

[[Hauptseite|zurück zur Hauptseite]]

[[Category:Bootmanager]]

Partition

2011-10-20T20:11:48Z

Josef-wien: Überschrift "NonRaid ..." angepaßt

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]] bis 11.4
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle sichern und wiederherstellen]]
* [[Verlorene Dateien wiederherstellen ext3 ext4|Gelöschte Dateien wiederherstellen ext3/ext4]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

NonRaid zu (software)Raid1 SuSE 10 1

2011-10-20T20:10:32Z

Josef-wien: "getestet mit" ergänzt um 11.4

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein [[RAID allgemein#Softwareraid|Software-RAID]] zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.

{{Box Test||
* SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos 
* open SUSE 10.2 Prinzipielles Funktionieren des Howto 
* open SUSE 10.3 Änderungen und Ergänzungen führten zur aktuellen Version 
* open SUSE 11.0 Prinzipielles Funktionieren des Howto 
* open SUSE 11.1 Kurztest
* open SUSE 11.2 Test und ein paar kleinere Updates
* open SUSE 11.3 Kurztest
* open SUSE 11.4 Kurztest
}}

{{ Box Hinweis||Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können.
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die '''fstab''' und GRUBs '''menu.lst'''. Erfahrungen mit '''mdadm''' können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: '''dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammelt haben''' }}

== Konfiguration des Ausgangssystems ==

Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :
automat:/proc # fdisk -l

Disk /dev/sda: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 65 66544 83 Linux
/dev/sda2 66 5186 5243904 83 Linux
/dev/sda3 5187 25667 20972544 83 Linux
/dev/sda4 25668 35003 9560064 f W95 Ext'd (LBA)
/dev/sda5 25668 27716 2098160 82 Linux swap / Solaris
/dev/sda6 27717 35003 7461872 83 Linux

Disk /dev/sdb: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 35003 35843056 83 Linux

automat:/proc # cat /etc/fstab
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda5 swap swap pri=42 0 0
/dev/sda1 /boot ext2 acl,user_xattr 1 2
/dev/sda3 /home ext3 acl,user_xattr 1 2
/dev/sda6 /data ext2 auto,ro 1 2
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
sysfs /sys sysfs noauto 0 0
/dev/fd0 /media/floppy auto noauto,user,sync 0 0

Es gibt also zwei gleiche Platten, wovon '''sdb''' derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( '''/home''' , ''' /data''' ), auch ''' /boot ''' ist ein separates Filesystem.

{{Box Hinweis||Das Howto ist so geschrieben, dass es egal ist, ob das '''/boot-Verzeichnis''' auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen}}

== Anlegen einer identischen Partitionstabelle ==

Zuerst klonen wir die gesamte Partionstabelle von '''sda''' nach '''sdb''':

automat:/proc # sfdisk -d /dev/sda > /tmp/sda.txt
automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sdb1 0+ 35002 35003- 35843056 83 Linux
/dev/sdb2 0 - 0 0 0 Empty
/dev/sdb3 0 - 0 0 0 Empty
/dev/sdb4 0 - 0 0 0 Empty
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 * 32 133119 133088 83 Linux
/dev/sdb2 133120 10620927 10487808 83 Linux
/dev/sdb3 10620928 52566015 41945088 83 Linux
/dev/sdb4 52566016 71686143 19120128 f W95 Ext'd (LBA)
/dev/sdb5 52566048 56762367 4196320 82 Linux swap / Solaris
/dev/sdb6 56762400 71686143 14923744 83 Linux
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
'''fdisk -l''' zeigt nun, dass alle Partitionen auf '''sda''' und '''sdb''' gleich sind. Da '''sdb''' z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen. 
In diesem Fall die Option '''--force''' probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigenem Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte [[Partitionstabelle sichern und wiederherstellen|hier]] nachlesen.

== Raid für das zukünftige Rootfilesystem erstellen ==

Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
'''sda''' wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.
{{OpenSUSE|10.3|
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.

Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird, reicht folgender Befehl
ls /etc/init.d/boot.d/*boot.md
kommt hier als Antwort
ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.
insserv /etc/init.d/boot.md
}}

So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit '''sdb2''' als einziger aktive Komponente.
Zunächst wird die Partitions-ID von '''sdb2''' geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon, aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''

automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Done
automat:/proc # sfdisk -R /dev/sdb

Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
Das wird unser zukünftiges Rootfilesystem aufnehmen.

automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
mdadm: /dev/sdb2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
Continue creating array? y
mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

und/oder

automat:/proc # mdadm -D /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Sat Aug 19 21:27:47 2006
Raid Level : raid1
Array Size : 5243840 (5.00 GiB 5.37 GB)
Device Size : 5243840 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Aug 19 21:27:47 2006
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
Events : 0.1

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 18 1 active sync /dev/sdb2

Wir tragen jetzt unser konfiguriertes RAID-Device in die '''mdadm.conf''' ein. Es ist erforderlich, eine DEVICES-Zeile in '''mdadm.conf''' einzufügen (sofern dies noch nicht geschehen ist), damit [http://linux.die.net/man/8/mdadm mdadm] beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in '''mdadm.conf''' ein:

automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
automat:/ # cat /etc/mdadm.conf
DEVICE /dev/sd[a-z][0-9]
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf '''/dev/md0''' anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.

automat:/ # mkfs.ext3 -j /dev/md0
...
...
automat:/ # mount /dev/md0 /mnt
automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei '''/mnt/''' ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von [http://linux.die.net/man/1/rsync rsync] gegenüber anderen Programmen ist ACLs (''' -A ''') und Xattrs (''' -X ''') übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option ''' -A ''' ist vor SUSE Linux 10.1 nicht vorhanden; die Option ''' -X ''' nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich ''' --delete-during ''' (sollte die Option nicht bekannt sein, ist auf ''' --delete ''' auszuweichen) aufzurufen.

Jetzt ändern wir auf dem "neuem" Rootfilesystem die '''etc/fstab'''

automat:/ # cd /mnt/etc
automat:/mnt/etc # vi fstab
/dev/sda2 / ext3 acl,user_xattr 1 1 (dieses ist der alte Zeile)
/dev/md0 / ext3 acl,user_xattr 1 1 (das ist geänderte Zeile)

{{OpenSUSE|10.3|
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.

erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid
<pre>
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 / ext3 acl,user_xattr 1 1
/dev/md0 / ext3 acl,user_xattr 1 1
</pre>
}}

Das Filesystem wird dann wieder umount'ed und die '''/boot/grub/menu.lst''' angepasst:

automat:/mnt/etc # cd /
automat:/ # umount /mnt
automat:/ # cd /boot/grub
automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das '''root=''' Argument so, dass nun '''md0''' als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:

#(normaler Booteintrag bleibt stehen)
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd
#(nachfolgender Booteintrag kommt neu hinzu)
#--------- RAID----------#
title SUSE RAID 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd

{{OpenSUSE|10.3|
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.

<pre>
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>
}}

Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus '''mdadm.conf''' und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von '''mkinitrd''' automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0

automat:/ # mkinitrd -f md -d /dev/md0

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.

'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.

== Anlegen der restlichen Raiddevices ==

Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
/dev/sda6 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher.
Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne '''sda''' zu verändern.

{{Kasten rot|Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.}}

Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

sfdisk --change-id /dev/sdb 1 fd
sfdisk --change-id /dev/sdb 3 fd
sfdisk --change-id /dev/sdb 5 fd
sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2 missing /dev/sdb1
mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2 missing /dev/sdb5
mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2 missing /dev/sdb3
mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2 missing /dev/sdb6

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md4 : active raid1 sdb6[1]
7461760 blocks [2/1] [_U]

md3 : active raid1 sdb3[1]
20972480 blocks [2/1] [_U]

md2 : active raid1 sdb5[1]
2098048 blocks [2/1] [_U]

md1 : active raid1 sdb1[1]
66432 blocks [2/1] [_U]

md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Danach müssen die neuen RAID-Devices in der '''mdadm.conf''' eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Notiz-Zettel hilft hier sicher ;-)''

'''Zwischenbemerkung:''' Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem" neu anlegen.

mkswap /dev/md2
mkfs.ext2 /dev/md1
mkfs.ext3 -j /dev/md3
mkfs.ext2 /dev/md4

Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von [http://linux.die.net/man/1/cp cp], über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird [http://www.bellevuelinux.org/man/cpio.1.html cpio] dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein. 
{{blau|; Man kann sich etwa an folgendem orientieren:
wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als '''cpio''' nehmen sollte. Dann könnte man hier zB mit [http://linux.die.net/man/1/rsync rsync] ( schon oben beim kopieren der Rootpartition beschrieben) oder mit [http://linux.die.net/man/1/star star] und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein '''tar''' als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.}}

automat:/ # mount /dev/md1 /mnt
automat:/ # cd /boot
automat:/boot # find . -mount | cpio -pdumC65536 /mnt
349 blocks
automat:/boot # umount /mnt
automat:/boot # mount /dev/md3 /mnt
automat:/boot # cd /home
automat:/home # find . -mount | cpio -pdumC65536 /mnt
53011 blocks
automat:/home # umount /mnt
automat:/home # mount /dev/md4 /mnt
automat:/home # cd /data
automat:/data # find . -mount | cpio -pdumC65536 /mnt
52731 blocks

Natürlich ist jetzt noch die '''/etc/fstab''' anzupassen:
''bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht''

automat:/data # cat /etc/fstab
/dev/md0 / ext3 acl,user_xattr 1 1
/dev/md2 swap swap pri=42 0 0
/dev/md1 /boot ext2 acl,user_xattr 1 2
/dev/md3 /home ext3 acl,user_xattr 1 2
/dev/md4 /data ext2 auto,ro 1 2
.....

'''2. Teil fertig:''' An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem '''/boot'''. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.

== Prüfen des Systems vor dem entgültigen Spiegeln ==

Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

automat:~ # swapon -s
Filename Type Size Used Priority
/dev/md2 partition 2098040 0 42
automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md1 on /boot type ext2 (rw,acl,user_xattr)
/dev/md3 on /home type ext3 (rw,acl,user_xattr)
/dev/md4 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von [http://linux.die.net/man/8/swapon swapon] als auch von [http://linux.die.net/man/8/mount mount] sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,

{{Box Achtung||'''wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen''', ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.}}

Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:
* bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
* ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
* die initrd wurde neu erstellt und hat jetzt Raidsupport
alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.

== Herstellung der Spiegelung ==

Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

{{Box Achtung||'''Ab hier wird das alte System nicht mehr bootfähig.'''}}

sfdisk --change-id /dev/sda 1 fd
sfdisk --change-id /dev/sda 2 fd
sfdisk --change-id /dev/sda 3 fd
sfdisk --change-id /dev/sda 5 fd
sfdisk --change-id /dev/sda 6 fd

mdadm /dev/md4 -a /dev/sda6
mdadm /dev/md3 -a /dev/sda3
mdadm /dev/md2 -a /dev/sda5
mdadm /dev/md1 -a /dev/sda1
mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md1 : active raid1 sda1[0] sdb1[1]
66432 blocks [2/2] [UU]

md3 : active raid1 sda3[0] sdb3[1]
20972480 blocks [2/1] [_U]
[==>..................] recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec

md4 : active raid1 sda6[0] sdb6[1]
7461760 blocks [2/2] [UU]

md2 : active raid1 sda5[0] sdb5[1]
2098048 blocks [2/1] [_U]
resync=DELAYED

md0 : active raid1 sda2[2] sdb2[1]
5243840 blocks [2/1] [_U]
resync=DELAYED

unused devices: <none>

{{Box Achtung||
Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten}}

== Konfiguration von Grub ==

=== Konfiguration von /boot/grub/menu.lst ===

Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die '''/boot/grub/menu.lst'''.
Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.
root=
resume=
dort sollte überall jetzt ein /dev/md? stehen.

Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen '''(hd?,?)''' Einträgen. Zur Sicherheit geben wir die '''Kernel''' und die '''initrd''' mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für '''Kernel''' und '''initrd''' nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.

{{blau|man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB
kann die Platten nur einzeln sehen.}}

Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über [[Grub]] gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht.

So hier sollten diese Booteinträge nach der Änderung dann aussehen: (''' man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt''' 
(''ich habe [http://wiki.linux-club.de/opensuse/Diskussion:NonRaid_zu_%28software%29Raid1_SuSE_10_1#Beispiel_einer_menu.lst_bei_openSUSE_10.3 hier] auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.'')

automat:/boot/grub # vi menu.lst
# Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
color white/blue black/light-gray
default 0
fallback 1
timeout 8
gfxmenu (hd0,0)/message

#--------- RAID----------#
title SUSE RAID 10.1 1-Platte
root (hd0,0)
kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd0,0)/initrd

#--------- RAID----------#
title SUSE RAID 10.1 2-Platte
root (hd1,0)
kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd1,0)/initrd

=== Erzeugen der Bootloader im MBR auf beiden Spiegelplatten ===

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei [[Grub]] vorbeischauen.
; root (hd1,0) : bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der '''Partition 1''' der Platte die in '''/boot/grub/device.map''' als '''hd1''' geführt wird
; setup (hd1) : und werden konfiguriert für den MBR eben dieser Platte '''hd1'''.
und das Ganze konfigurieren wir für beide Platten.

automat:/boot/grub # grub

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

== Aufnahme der neuen Platte in die /boot/grub/device.map ==

Bislang steht in der Datei nur

(fd0) /dev/fd0
(hd0) /dev/sda

Die folgenden Zeile muss noch zugefügt werden.

(hd1) /dev/sdb

== Abschließende Konfiguration ==

Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der '''initrd''' bekannt sind.

automat:/boot/grub # mkinitrd -f md

Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ('''faulty''') geht: an das Ende der '''mdadm.conf''' fügen wir unsere Mailaddresse ein.
echo "MAILADDR root@localhost" >> /etc/mdadm.conf

Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den '''mdadmd-Deamon''' starten, entweder über YaST oder mittels '''insserv'''
insserv /etc/init.d/mdadmd

'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im BIOS auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.

== weitere Optionale Konfigurationen ==

{{openSUSE|10.3|Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der '''/etc/fstab''' und in der '''/boot/grub/menu.lst''' die Einträge manuell wieder auf DISK-BY-ID umstellen,
die genauen Werte die zu benutzen sind kann man zB mit:
ls -l /dev/disk/by-id/md-uuid*
abfragen. ''( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)'' }}

Wer ganz sicher gehen will trägt noch das Raidmodul in die '''/etc/sysconfig/kernel''' in die Zeile '''INITRD_MODULES=''' ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von '''mkinitrd''' das Rootdevice ein Raid ist, wird [http://linux.die.net/man/8/mkinitrd mkinitrd] das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.

[[Category:Partitionen]]

Zwei Kernel parallel installieren

2011-05-19T16:20:15Z

Josef-wien: Bedeutung von kernel-xxx-base ab 11.2 ergänzt und bevorzugte Variante eingefügt.

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1, 11.3, 11.4
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln. D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

Mit Ausnahme von openSUSE 11.1 besteht der kompilierte Kernel aus einer *.rpm-Datei. Bei openSUSE 11.1 sind es mit Ausnahme des Vanilla-Kernel drei *.rpm-Dateien (kernel-xxx, kernel-xxx-base und kernel-xxx-extra, xxx steht für den Kernel-Typ, z.B. default), die als Einheit betrachtet werden sollen; die Datei kernel-xxx-extra sollte nur dann weggelassen werden, wenn man ganz sicher ist, diese Module nicht zu benötigen. Ab openSUSE 11.2 ist das Paket kernel-xxx-base nur eine relativ kleine Teilmenge von kernel-xxx und für den normalen Anwender nicht zielführend.

== Bevorzugte Variante ==

Seit einigen openSUSE-Versionen ist es möglich, mit zypper (und damit auch mit YaST) mehrere Kernel desselben Typs zu installieren. Dazu muss in der Datei /etc/zypp/zypp.conf die Zeile
multiversion = provides:multiversion(kernel)
aktiviert werden.

== Früher notwendige Varianten ==

=== Erste Variante ===

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

=== Zweite Variante ===

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

Unter openSUSE 11.1 ist diese Variante aufgrund von Abhängigkeitsproblem leider nicht mehr möglich.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Ab openSUSE 11.1 (und möglicherweise früher) genügt es jetzt im Normalfall zu überprüfen, ob der Kernel in <code>/boot/grub/menu.lst</code> richtig eingetragen wurde. Nur bei älteren Versionen ist es wichtig zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>. Neuere openSUSE-Versionen schreiben nämlich nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>. Bei Bedarf muss darum zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

GRUB wiederherstellen

2011-05-19T15:41:10Z

Josef-wien:

__FORCETOC__
== Einleitung ==

Aus verschiedenen Gründen kann es erforderlich werden, den Bootloader GRUB neu zu installieren. Mögliche Gründe können sein:
* Der alte GRUB wurde "verbastelt"
* Es wurde ein Windows installiert, welches regelmäßig bei der Installation den Linux Bootloader GRUB überschreibt

== GRUB wiederherstellen unter [[OpenSUSE]] ==

=== GRUB im Boot-Sektor einer Partition ===

Standardmäßig schreibt bzw. beläßt openSUSE einen generischen MBR (''master boot record'') und installiert GRUB (''GNU GRUB, the GRand Unified Bootloader'') entweder in die Systempartition (wenn diese eine primäre Partition ist) oder in die erweiterte Partition (wenn die Systempartition eine logische Partition ist). Ein generischer MBR bewirkt, daß eine als "aktiv" gekennzeichnete Partition gesucht und der Bootcode (also GRUB) der ersten gefundenen ausgeführt wird.

Durch eine Windows-Installation oder -Reparatur wird die Windows-Systempartition als "aktiv" gekennzeichnet, daher startet nur mehr Windows. Um den vorherigen Zustand wiederherzustellen, muss die den Bootcode von GRUB enthaltende Partition (also entweder die System- oder die erweiterte Partition) als "aktiv" gekennzeichnet werden. Dazu wird von der openSUSE-DVD das Rettungssystem gestartet und nach der Anmeldung als root (ein Paßwort ist nicht erforderlich) z. B. der Befehl
sfdisk -AY /dev/sdX
(Y ist die Partition und X die Platte) ausgeführt. '''Beispiel:''' Um /dev/sda4 als "aktiv" kennzuzeichnen, ist der Befehl
sfdisk -A4 /dev/sda
zu verwenden. Alternativ kann für diesen Befehl auch ein Live-System verwendet werden.

=== GRUB im MBR ===

Falls an Stelle der Standardvorgabe GRUB in den MBR installiert wurde, wird durch eine Windows-Installation oder -Reparatur ein generischer MBR angelegt. Um GRUB wieder in den MBR zu installieren, sind im Rettungssystem folgende Befehle auszuführen:
grub
find /boot/grub/stage1
root (hdX,Y) <== hierher kommt das Ergebnis von find, z. B.: root (hd0,2)
setup (hd0)
quit
In diesem Fall kann die Windows-Systempartition als "aktiv" gekennzeichnet bleiben.

Wenn der generische MBR bleiben soll, muss in der Zeile "setup" die System- bzw. die erweiterte Partition angegeben und diese Partition als "aktiv" gekennzeichnet werden.

=== Hinweise ===

Wenn eine eigene primäre Boot-Partition eingerichtet wurde, ist natürlich diese und nicht die Systempartition anzugeben.

Wenn Linux nicht auf der Boot-Platte installiert wurde, muss GRUB in den MBR der Boot-Platte installiert werden.

GRUB beginnt die Zählung von Platte und Partition jeweils mit der Ziffer Null. Linux dagegen beginnt die Zählung der Platten mit dem Kleinbuchstaben a und der Partitionen mit der Ziffer Eins. Das ist zu berücksichtigen, wenn z. B. mit dem Befehl
fdisk -l
die Partitionierung angezeigt wird: (hd0,0) entspricht /dev/sda1, wenn nur eine Platte vorhanden ist, bei mehreren Platten muss deren Reihenfolge bei GRUB und Linux nicht identisch sein.

Primäre und erweiterte Partitionen liegen im Bereich von (hdX,0) bis (hdX,3) bzw. /dev/sdX1 bis /dev/sdX4, logische Partitionen beginnen ab (hdX,4) bzw. /dev/sdX5.

=== Alternative bis openSUSE 11.2 ===

Bis [[OpenSUSE]] 11.2 ist es sehr einfach, den Bootloader GRUB erneut zu installieren:
* Man bootet von seiner openSuse DVD
* Man wählt den Punkt "'''Installation'''" aus
* Anschließend wählt man die Sprache und bestätigt die Lizenzinformationen
* Nun wird man gefragt, was man tun möchte: "Neuinstallation", "Aktualisieren" oder "Weitere Optionen"
** An dieser Stelle wählt man den Punkt "'''Weitere Optionen'''"
** Nun markiert man noch "'''Reparatur des installierten Systems'''"
* Mit den jetzt erscheinenden Reparaturwerkzeugen hat man nun die Möglichkeit, den Bootloader GRUB neu zu installieren
** Der Punkt "'''Expertenwerkzeuge'''" hält hierbei ein spezielles Werkzeug "'''Neuen Bootloader installieren'''" bereit
Ab [[OpenSUSE]] 11.3 gibt es "'''Reparatur des installierten Systems'''" nicht mehr.

== GRUB wiederherstellen unter [[Ubuntu|Ubuntu/Kubuntu]] ==
* [http://wiki.ubuntuusers.de/GRUB#Bootloader Anleitung zur Wiederherstellung des Bootloaders aus dem Wiki von Ubuntuusers]

== Weitere Wege der Wiederherstellung/Installation von GRUB ==
* [[Grub-Install via "chroot" und Knoppix|In diesem Artikel hier im Wiki wird erklärt, wie man GRUB mittels einer Knoppix CD installieren kann.]] Dieser Artikel gilt nicht für openSUSE, da eine andere Version des Programms grub-install verwendet wird.

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

Partition

2011-04-30T15:00:39Z

Josef-wien:

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]] bis 11.3
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle sichern und wiederherstellen]]
* [[Verlorene Dateien wiederherstellen ext3 ext4|Gelöschte Dateien wiederherstellen ext3/ext4]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

NonRaid zu (software)Raid1 SuSE 10 1

2011-04-30T14:59:22Z

Josef-wien: "getestet mit" ergänzt um 11.3

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein [[RAID allgemein#Softwareraid|Software-RAID]] zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.

{{Box Test||
* SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos 
* open SUSE 10.2 Prinzipielles Funktionieren des Howto 
* open SUSE 10.3 Änderungen und Ergänzungen führten zur aktuellen Version 
* open SUSE 11.0 Prinzipielles Funktionieren des Howto 
* open SUSE 11.1 Kurztest
* open SUSE 11.2 Test und ein paar kleinere Updates
* open SUSE 11.3 Kurztest
}}

{{ Box Hinweis||Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können.
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die '''fstab''' und GRUBs '''menu.lst'''. Erfahrungen mit '''mdadm''' können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: '''dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammelt haben''' }}

== Konfiguration des Ausgangssystems ==

Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :
automat:/proc # fdisk -l

Disk /dev/sda: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 65 66544 83 Linux
/dev/sda2 66 5186 5243904 83 Linux
/dev/sda3 5187 25667 20972544 83 Linux
/dev/sda4 25668 35003 9560064 f W95 Ext'd (LBA)
/dev/sda5 25668 27716 2098160 82 Linux swap / Solaris
/dev/sda6 27717 35003 7461872 83 Linux

Disk /dev/sdb: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 35003 35843056 83 Linux

automat:/proc # cat /etc/fstab
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda5 swap swap pri=42 0 0
/dev/sda1 /boot ext2 acl,user_xattr 1 2
/dev/sda3 /home ext3 acl,user_xattr 1 2
/dev/sda6 /data ext2 auto,ro 1 2
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
sysfs /sys sysfs noauto 0 0
/dev/fd0 /media/floppy auto noauto,user,sync 0 0

Es gibt also zwei gleiche Platten, wovon '''sdb''' derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( '''/home''' , ''' /data''' ), auch ''' /boot ''' ist ein separates Filesystem.

{{Box Hinweis||Das Howto ist so geschrieben, dass es egal ist, ob das '''/boot-Verzeichnis''' auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen}}

== Anlegen einer identischen Partitionstabelle ==

Zuerst klonen wir die gesamte Partionstabelle von '''sda''' nach '''sdb''':

automat:/proc # sfdisk -d /dev/sda > /tmp/sda.txt
automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sdb1 0+ 35002 35003- 35843056 83 Linux
/dev/sdb2 0 - 0 0 0 Empty
/dev/sdb3 0 - 0 0 0 Empty
/dev/sdb4 0 - 0 0 0 Empty
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 * 32 133119 133088 83 Linux
/dev/sdb2 133120 10620927 10487808 83 Linux
/dev/sdb3 10620928 52566015 41945088 83 Linux
/dev/sdb4 52566016 71686143 19120128 f W95 Ext'd (LBA)
/dev/sdb5 52566048 56762367 4196320 82 Linux swap / Solaris
/dev/sdb6 56762400 71686143 14923744 83 Linux
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
'''fdisk -l''' zeigt nun, dass alle Partitionen auf '''sda''' und '''sdb''' gleich sind. Da '''sdb''' z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen. 
In diesem Fall die Option '''--force''' probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigenem Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte [[Partitionstabelle sichern und wiederherstellen|hier]] nachlesen.

== Raid für das zukünftige Rootfilesystem erstellen ==

Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
'''sda''' wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.
{{OpenSUSE|10.3|
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.

Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird, reicht folgender Befehl
ls /etc/init.d/boot.d/*boot.md
kommt hier als Antwort
ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.
insserv /etc/init.d/boot.md
}}

So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit '''sdb2''' als einziger aktive Komponente.
Zunächst wird die Partitions-ID von '''sdb2''' geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon, aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''

automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Done
automat:/proc # sfdisk -R /dev/sdb

Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
Das wird unser zukünftiges Rootfilesystem aufnehmen.

automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
mdadm: /dev/sdb2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
Continue creating array? y
mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

und/oder

automat:/proc # mdadm -D /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Sat Aug 19 21:27:47 2006
Raid Level : raid1
Array Size : 5243840 (5.00 GiB 5.37 GB)
Device Size : 5243840 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Aug 19 21:27:47 2006
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
Events : 0.1

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 18 1 active sync /dev/sdb2

Wir tragen jetzt unser konfiguriertes RAID-Device in die '''mdadm.conf''' ein. Es ist erforderlich, eine DEVICES-Zeile in '''mdadm.conf''' einzufügen (sofern dies noch nicht geschehen ist), damit [http://linux.die.net/man/8/mdadm mdadm] beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in '''mdadm.conf''' ein:

automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
automat:/ # cat /etc/mdadm.conf
DEVICE /dev/sd[a-z][0-9]
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf '''/dev/md0''' anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.

automat:/ # mkfs.ext3 -j /dev/md0
...
...
automat:/ # mount /dev/md0 /mnt
automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei '''/mnt/''' ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von [http://linux.die.net/man/1/rsync rsync] gegenüber anderen Programmen ist ACLs (''' -A ''') und Xattrs (''' -X ''') übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option ''' -A ''' ist vor SUSE Linux 10.1 nicht vorhanden; die Option ''' -X ''' nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich ''' --delete-during ''' (sollte die Option nicht bekannt sein, ist auf ''' --delete ''' auszuweichen) aufzurufen.

Jetzt ändern wir auf dem "neuem" Rootfilesystem die '''etc/fstab'''

automat:/ # cd /mnt/etc
automat:/mnt/etc # vi fstab
/dev/sda2 / ext3 acl,user_xattr 1 1 (dieses ist der alte Zeile)
/dev/md0 / ext3 acl,user_xattr 1 1 (das ist geänderte Zeile)

{{OpenSUSE|10.3|
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.

erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid
<pre>
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 / ext3 acl,user_xattr 1 1
/dev/md0 / ext3 acl,user_xattr 1 1
</pre>
}}

Das Filesystem wird dann wieder umount'ed und die '''/boot/grub/menu.lst''' angepasst:

automat:/mnt/etc # cd /
automat:/ # umount /mnt
automat:/ # cd /boot/grub
automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das '''root=''' Argument so, dass nun '''md0''' als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:

#(normaler Booteintrag bleibt stehen)
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd
#(nachfolgender Booteintrag kommt neu hinzu)
#--------- RAID----------#
title SUSE RAID 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd

{{OpenSUSE|10.3|
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.

<pre>
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>
}}

Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus '''mdadm.conf''' und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von '''mkinitrd''' automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0

automat:/ # mkinitrd -f md -d /dev/md0

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.

'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.

== Anlegen der restlichen Raiddevices ==

Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
/dev/sda6 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher.
Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne '''sda''' zu verändern.

{{Kasten rot|Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.}}

Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

sfdisk --change-id /dev/sdb 1 fd
sfdisk --change-id /dev/sdb 3 fd
sfdisk --change-id /dev/sdb 5 fd
sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2 missing /dev/sdb1
mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2 missing /dev/sdb5
mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2 missing /dev/sdb3
mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2 missing /dev/sdb6

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md4 : active raid1 sdb6[1]
7461760 blocks [2/1] [_U]

md3 : active raid1 sdb3[1]
20972480 blocks [2/1] [_U]

md2 : active raid1 sdb5[1]
2098048 blocks [2/1] [_U]

md1 : active raid1 sdb1[1]
66432 blocks [2/1] [_U]

md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Danach müssen die neuen RAID-Devices in der '''mdadm.conf''' eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Notiz-Zettel hilft hier sicher ;-)''

'''Zwischenbemerkung:''' Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem" neu anlegen.

mkswap /dev/md2
mkfs.ext2 /dev/md1
mkfs.ext3 -j /dev/md3
mkfs.ext2 /dev/md4

Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von [http://linux.die.net/man/1/cp cp], über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird [http://www.bellevuelinux.org/man/cpio.1.html cpio] dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein. 
{{blau|; Man kann sich etwa an folgendem orientieren:
wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als '''cpio''' nehmen sollte. Dann könnte man hier zB mit [http://linux.die.net/man/1/rsync rsync] ( schon oben beim kopieren der Rootpartition beschrieben) oder mit [http://linux.die.net/man/1/star star] und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein '''tar''' als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.}}

automat:/ # mount /dev/md1 /mnt
automat:/ # cd /boot
automat:/boot # find . -mount | cpio -pdumC65536 /mnt
349 blocks
automat:/boot # umount /mnt
automat:/boot # mount /dev/md3 /mnt
automat:/boot # cd /home
automat:/home # find . -mount | cpio -pdumC65536 /mnt
53011 blocks
automat:/home # umount /mnt
automat:/home # mount /dev/md4 /mnt
automat:/home # cd /data
automat:/data # find . -mount | cpio -pdumC65536 /mnt
52731 blocks

Natürlich ist jetzt noch die '''/etc/fstab''' anzupassen:
''bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht''

automat:/data # cat /etc/fstab
/dev/md0 / ext3 acl,user_xattr 1 1
/dev/md2 swap swap pri=42 0 0
/dev/md1 /boot ext2 acl,user_xattr 1 2
/dev/md3 /home ext3 acl,user_xattr 1 2
/dev/md4 /data ext2 auto,ro 1 2
.....

'''2. Teil fertig:''' An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem '''/boot'''. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.

== Prüfen des Systems vor dem entgültigen Spiegeln ==

Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

automat:~ # swapon -s
Filename Type Size Used Priority
/dev/md2 partition 2098040 0 42
automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md1 on /boot type ext2 (rw,acl,user_xattr)
/dev/md3 on /home type ext3 (rw,acl,user_xattr)
/dev/md4 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von [http://linux.die.net/man/8/swapon swapon] als auch von [http://linux.die.net/man/8/mount mount] sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,

{{Box Achtung||'''wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen''', ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.}}

Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:
* bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
* ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
* die initrd wurde neu erstellt und hat jetzt Raidsupport
alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.

== Herstellung der Spiegelung ==

Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

{{Box Achtung||'''Ab hier wird das alte System nicht mehr bootfähig.'''}}

sfdisk --change-id /dev/sda 1 fd
sfdisk --change-id /dev/sda 2 fd
sfdisk --change-id /dev/sda 3 fd
sfdisk --change-id /dev/sda 5 fd
sfdisk --change-id /dev/sda 6 fd

mdadm /dev/md4 -a /dev/sda6
mdadm /dev/md3 -a /dev/sda3
mdadm /dev/md2 -a /dev/sda5
mdadm /dev/md1 -a /dev/sda1
mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md1 : active raid1 sda1[0] sdb1[1]
66432 blocks [2/2] [UU]

md3 : active raid1 sda3[0] sdb3[1]
20972480 blocks [2/1] [_U]
[==>..................] recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec

md4 : active raid1 sda6[0] sdb6[1]
7461760 blocks [2/2] [UU]

md2 : active raid1 sda5[0] sdb5[1]
2098048 blocks [2/1] [_U]
resync=DELAYED

md0 : active raid1 sda2[2] sdb2[1]
5243840 blocks [2/1] [_U]
resync=DELAYED

unused devices: <none>

{{Box Achtung||
Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten}}

== Konfiguration von Grub ==

=== Konfiguration von /boot/grub/menu.lst ===

Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die '''/boot/grub/menu.lst'''.
Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.
root=
resume=
dort sollte überall jetzt ein /dev/md? stehen.

Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen '''(hd?,?)''' Einträgen. Zur Sicherheit geben wir die '''Kernel''' und die '''initrd''' mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für '''Kernel''' und '''initrd''' nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.

{{blau|man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB
kann die Platten nur einzeln sehen.}}

Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über [[Grub]] gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht.

So hier sollten diese Booteinträge nach der Änderung dann aussehen: (''' man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt''' 
(''ich habe [http://wiki.linux-club.de/opensuse/Diskussion:NonRaid_zu_%28software%29Raid1_SuSE_10_1#Beispiel_einer_menu.lst_bei_openSUSE_10.3 hier] auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.'')

automat:/boot/grub # vi menu.lst
# Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
color white/blue black/light-gray
default 0
fallback 1
timeout 8
gfxmenu (hd0,0)/message

#--------- RAID----------#
title SUSE RAID 10.1 1-Platte
root (hd0,0)
kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd0,0)/initrd

#--------- RAID----------#
title SUSE RAID 10.1 2-Platte
root (hd1,0)
kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd1,0)/initrd

=== Erzeugen der Bootloader im MBR auf beiden Spiegelplatten ===

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei [[Grub]] vorbeischauen.
; root (hd1,0) : bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der '''Partition 1''' der Platte die in '''/boot/grub/device.map''' als '''hd1''' geführt wird
; setup (hd1) : und werden konfiguriert für den MBR eben dieser Platte '''hd1'''.
und das Ganze konfigurieren wir für beide Platten.

automat:/boot/grub # grub

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

== Aufnahme der neuen Platte in die /boot/grub/device.map ==

Bislang steht in der Datei nur

(fd0) /dev/fd0
(hd0) /dev/sda

Die folgenden Zeile muss noch zugefügt werden.

(hd1) /dev/sdb

== Abschließende Konfiguration ==

Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der '''initrd''' bekannt sind.

automat:/boot/grub # mkinitrd -f md

Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ('''faulty''') geht: an das Ende der '''mdadm.conf''' fügen wir unsere Mailaddresse ein.
echo "MAILADDR root@localhost" >> /etc/mdadm.conf

Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den '''mdadmd-Deamon''' starten, entweder über YaST oder mittels '''insserv'''
insserv /etc/init.d/mdadmd

'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im BIOS auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.

== weitere Optionale Konfigurationen ==

{{openSUSE|10.3|Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der '''/etc/fstab''' und in der '''/boot/grub/menu.lst''' die Einträge manuell wieder auf DISK-BY-ID umstellen,
die genauen Werte die zu benutzen sind kann man zB mit:
ls -l /dev/disk/by-id/md-uuid*
abfragen. ''( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)'' }}

Wer ganz sicher gehen will trägt noch das Raidmodul in die '''/etc/sysconfig/kernel''' in die Zeile '''INITRD_MODULES=''' ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von '''mkinitrd''' das Rootdevice ein Raid ist, wird [http://linux.die.net/man/8/mkinitrd mkinitrd] das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.

[[Category:Partitionen]]

GRUB wiederherstellen

2011-02-28T16:46:22Z

Josef-wien: Beispiel für sfdisk eingefügt

__FORCETOC__
== Einleitung ==

Aus verschiedenen Gründen kann es erforderlich werden, den Bootloader GRUB neu zu installieren. Mögliche Gründe können sein:
* Der alte GRUB wurde "verbastelt"
* Es wurde ein Windows installiert, welches regelmäßig bei der Installation den Linux Bootloader GRUB überschreibt

== GRUB wiederherstellen unter [[OpenSUSE]] ==

=== GRUB im Boot-Sektor einer Partition ===

Standardmäßig schreibt bzw. beläßt openSUSE einen generischen MBR (''master boot record'') und installiert GRUB (''GNU GRUB, the GRand Unified Bootloader'') entweder in die Systempartition (wenn diese eine primäre Partition ist) oder in die erweiterte Partition (wenn die Systempartition eine logische Partition ist). Ein generischer MBR bewirkt, daß eine als "aktiv" gekennzeichnete Partition gesucht und der Bootcode (also GRUB) der ersten gefundenen ausgeführt wird.

Durch eine Windows-Installation oder -Reparatur wird die Windows-Systempartition als "aktiv" gekennzeichnet, daher startet nur mehr Windows. Um den vorherigen Zustand wiederherzustellen, muss die den Bootcode von GRUB enthaltende Partition (also entweder die System- oder die erweiterte Partition) als "aktiv" gekennzeichnet werden. Dazu wird von der openSUSE-DVD das Rettungssystem gestartet und nach der Anmeldung als root (ein Paßwort ist nicht erforderlich) z. B. der Befehl
sfdisk -AY /dev/sdX
(Y ist die Partition und X die Platte) ausgeführt. '''Beispiel:''' Um /dev/sda4 als "aktiv" kennzuzeichnen, ist der Befehl
sfdisk -A4 /dev/sda
zu verwenden. Alternativ kann für diesen Befehl auch ein Live-System verwendet werden.

=== GRUB im MBR ===

Falls an Stelle der Standardvorgabe GRUB in den MBR installiert wurde, wird durch eine Windows-Installation oder -Reparatur ein generischer MBR angelegt. Um GRUB wieder in den MBR zu installieren, sind im Rettungssystem folgende Befehle auszuführen:
grub
find /boot/grub/stage1
root (hdX,Y) <== hierher kommt das Ergebnis von find, z. B.: root (hd0,2)
setup (hd0)
quit
In diesem Fall kann die Windows-Systempartition als "aktiv" gekennzeichnet bleiben.

Wenn der generische MBR bleiben soll, muss in der Zeile "setup" die System- bzw. die erweiterte Partition angegeben und diese Partition als "aktiv" gekennzeichnet werden.

=== Hinweise ===

Wenn eine eigene primäre Boot-Partition eingerichtet wurde, ist natürlich diese und nicht die Systempartition anzugeben.

Wenn Linux nicht auf der Boot-Platte installiert wurde, muss GRUB in den MBR der Boot-Platte installiert werden.

GRUB beginnt die Zählung von Platte und Partition jeweils mit der Ziffer Null. Linux dagegen beginnt die Zählung der Platten mit dem Kleinbuchstaben a und der Partitionen mit der Ziffer Eins. Das ist zu berücksichtigen, wenn z. B. mit dem Befehl
fdisk -l
die Partitionierung angezeigt wird: (hd0,0) entspricht /dev/sda1, wenn nur eine Platte vorhanden ist, bei mehreren Platten muss deren Reihenfolge bei GRUB und Linux nicht identisch sein.

Primäre und erweiterte Partitionen liegen im Bereich von (hdX,0) bis (hdX,3) bzw. /dev/sdX1 bis /dev/sdX4, logische Partitionen beginnen ab (hdX,4) bzw. /dev/sdX5.

=== Alternative bis openSUSE 11.2 ===

Bis [[OpenSUSE]] 11.2 ist es sehr einfach, den Bootloader GRUB erneut zu installieren:
* Man bootet von seiner openSuse DVD
* Man wählt den Punkt "'''Installation'''" aus
* Anschließend wählt man die Sprache und bestätigt die Lizenzinformationen
* Nun wird man gefragt, was man tun möchte: "Neuinstallation", "Aktualisieren" oder "Weitere Optionen"
** An dieser Stelle wählt man den Punkt "'''Weitere Optionen'''"
** Nun markiert man noch "'''Reparatur des installierten Systems'''"
* Mit den jetzt erscheinenden Reparaturwerkzeugen hat man nun die Möglichkeit, den Bootloader GRUB neu zu installieren
** Der Punkt "'''Expertenwerkzeuge'''" hält hierbei ein spezielles Werkzeug "'''Neuen Bootloader installieren'''" bereit
Bei [[OpenSUSE]] 11.3 gibt es "'''Reparatur des installierten Systems'''" nicht mehr.

== GRUB wiederherstellen unter [[Ubuntu|Ubuntu/Kubuntu]] ==
* [http://wiki.ubuntuusers.de/GRUB#Bootloader Anleitung zur Wiederherstellung des Bootloaders aus dem Wiki von Ubuntuusers]

== Weitere Wege der Wiederherstellung/Installation von GRUB ==
* [[Grub-Install via "chroot" und Knoppix|In diesem Artikel hier im Wiki wird erklärt, wie man GRUB mittels einer Knoppix CD installieren kann.]] Dieser Artikel gilt nicht für openSUSE, da eine andere Version des Programms grub-install verwendet wird.

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

Grub-Install via "chroot" und Knoppix

2011-02-26T16:23:14Z

Josef-wien: Hinweis am Anfang eingefügt

__FORCETOC__
{{Box Hinweis|'''Gilt nicht für openSUSE''' |Dieser Artikel gilt nicht für openSUSE, da eine andere Version des Programms grub-install verwendet wird: Das Programm muß ohne Parameter aufgerufen werden und führt den Befehl ''grub --batch < /etc/grub.conf'' aus. Wenn die Datei /etc/grub.conf nicht vorhanden ist, wird sie mit dem Befehl ''/sbin/yast2 bootloader'' erzeugt.
}}

== Grub-Install via "chroot" und Knoppix ==

Aus den verschiedensten Gründen kann es erforderlich sein den Bootmanager erneut (oder erstmals) in den mbr einer Platte installieren zu müssen.

Wie so oft, gibt es dafür die unterschiedlichsten Wege.
Ich möchte hier versuchen den Weg mittels Knoppix und einer "chroot"-Umgebung zu erläutern.

(Wobei dieser Weg sicher auch mit anderen Live-CD's möglich ist, z.B. Kanotix)

'''1. Allgemein zu chroot'''

Mit "chroot" lässt man ein Kommando oder eine interaktive Shell in einem speziellem Wurzelverzeichnis laufen.

'''2. Vorgehen'''

- mit [http://www.knopper.net/knoppix/ Knoppix-CD] booten (auf die Voraussetzungen für das Booten von CD will ich an dieser Stelle nicht eingehen)

- eine Shell öffnen und zu root werden

dazu ein Zitat aus den Knoppix-FAQ's:

F: Wie lautet das root-Passwort?

A: Es gibt keines, alle Passwörter sind per default gesperrt.
Unter KNOPPIX/README_Security.txt sind einige Hinweise zu diesem Thema
nachzulesen.

su -

- die /-Partition des installierten Linux mounten (wenn nicht schon durch Knoppix beim Booten passiert):
mount -o rw /dev/hda2 /mnt

wenn diese Partition auf hda2 liegt - diese Angabe müsst ihr entsprechend euren Gegebenheiten anpassen.

Wurde die Partition von Knoppix bereits gemountet, kann aber trotzdem ein remounten erforderlich sein, da Knoppix diese evt. nur "read-only" gemountet hat:
mount -o remount,rw /dev/hda2 /mnt

- diese gemountete Partition zum "neuen" Wurzelverzeichnis machen:
mount --bind /dev /mnt/dev
chroot /mnt

Wenn mehrere Partitionen zu mounten sind (/var,/usr,...) und /mnt, /proc, usw. automatisch gemountet werden sollen, kann statt chroot auch openroot verwendet werden:
openroot /mnt
[http://www.elstel.com/openroot/ Download und weiterführende Infos zu openroot hier]

- Grub in den mbr von hda installieren:
grub-install /dev/hda

Sollten Änderungen an der menu.lst von Grub erforderlich sein, dann kann/sollte man dies natürlich vor dem Installieren des Bootmanagers tun:
vi /boot/grub/menu.lst

oder einen anderen Editor verwenden - das ist eurer Wahl.

Und nun den PC rebooten ... und *Daumendrück*

Aber nicht vergessen, die Knoppix-CD zuvor entfernen.

'''Hinweis:'''

Wenn /boot (Home von Grub ) sich auf einer anderen Partition befindet sollte die Partition erst nach
dem chroot mit mount eingebunden werden.

Dann kann Grub den Filesystemtyp erkennen, wenn dieser unterschiedlich zu der Root-Partition ist.

Sonst bleibt Grub u.U. beim Booten im Stage 1_5 stehen.

== Grub-Install '''ohne''' "chroot" und Knoppix ==

PS1: Mittlerweile ist ein chroot nicht mehr unbedingt erforderlich.
Um Grub erneut zu installieren genügt inzwischen:
grub-install --recheck --no-floppy --root-directory=/mountpoint/der/root /dev/hda

PS2: mit "chroot" kann man natürlich noch viel mehr tun ... wen es interessiert schaut in die Man-Pages.

== Quellenangaben und weiterführende Links ==
* [http://www.knopper.net/knoppix/ Homepage von Knoppix]

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

GRUB wiederherstellen

2011-02-26T15:56:45Z

Josef-wien: Erweiterung um die Punkte "GRUB im Boot-Sektor einer Partition", "GRUB im MBR" und "Hinweise"

__FORCETOC__
== Einleitung ==

Aus verschiedenen Gründen kann es erforderlich werden, den Bootloader GRUB neu zu installieren. Mögliche Gründe können sein:
* Der alte GRUB wurde "verbastelt"
* Es wurde ein Windows installiert, welches regelmäßig bei der Installation den Linux Bootloader GRUB überschreibt

== GRUB wiederherstellen unter [[OpenSUSE]] ==

=== GRUB im Boot-Sektor einer Partition ===

Standardmäßig schreibt bzw. beläßt openSUSE einen generischen MBR (''master boot record'') und installiert GRUB (''GNU GRUB, the GRand Unified Bootloader'') entweder in die Systempartition (wenn diese eine primäre Partition ist) oder in die erweiterte Partition (wenn die Systempartition eine logische Partition ist). Ein generischer MBR bewirkt, daß eine als "aktiv" gekennzeichnete Partition gesucht und der Bootcode (also GRUB) der ersten gefundenen ausgeführt wird.

Durch eine Windows-Installation oder -Reparatur wird die Windows-Systempartition als "aktiv" gekennzeichnet, daher startet nur mehr Windows. Um den vorherigen Zustand wiederherzustellen, muss die den Bootcode von GRUB enthaltende Partition (also entweder die System- oder die erweiterte Partition) als "aktiv" gekennzeichnet werden. Dazu wird von der openSUSE-DVD das Rettungssystem gestartet und nach der Anmeldung als root (ein Paßwort ist nicht erforderlich) z. B. der Befehl
sfdisk -AY /dev/sdX
(Y ist die Partition und X die Platte) ausgeführt. Alternativ kann für diesen Befehl auch ein Live-System verwendet werden.

=== GRUB im MBR ===

Falls an Stelle der Standardvorgabe GRUB in den MBR installiert wurde, wird durch eine Windows-Installation oder -Reparatur ein generischer MBR angelegt. Um GRUB wieder in den MBR zu installieren, sind im Rettungssystem folgende Befehle auszuführen:
grub
find /boot/grub/stage1
root (hdX,Y) <== hierher kommt das Ergebnis von find, z. B.: root (hd0,2)
setup (hd0)
quit
In diesem Fall kann die Windows-Systempartition als "aktiv" gekennzeichnet bleiben.

Wenn der generische MBR bleiben soll, muss in der Zeile "setup" die System- bzw. die erweiterte Partition angegeben und diese Partition als "aktiv" gekennzeichnet werden.

=== Hinweise ===

Wenn eine eigene primäre Boot-Partition eingerichtet wurde, ist natürlich diese und nicht die Systempartition anzugeben.

Wenn Linux nicht auf der Boot-Platte installiert wurde, muss GRUB in den MBR der Boot-Platte installiert werden.

GRUB beginnt die Zählung von Platte und Partition jeweils mit der Ziffer Null. Linux dagegen beginnt die Zählung der Platten mit dem Kleinbuchstaben a und der Partitionen mit der Ziffer Eins. Das ist zu berücksichtigen, wenn z. B. mit dem Befehl
fdisk -l
die Partitionierung angezeigt wird: (hd0,0) entspricht /dev/sda1, wenn nur eine Platte vorhanden ist, bei mehreren Platten muss deren Reihenfolge bei GRUB und Linux nicht identisch sein.

Primäre und erweiterte Partitionen liegen im Bereich von (hdX,0) bis (hdX,3) bzw. /dev/sdX1 bis /dev/sdX4, logische Partitionen beginnen ab (hdX,4) bzw. /dev/sdX5.

=== Alternative bis openSUSE 11.2 ===

Bis [[OpenSUSE]] 11.2 ist es sehr einfach, den Bootloader GRUB erneut zu installieren:
* Man bootet von seiner openSuse DVD
* Man wählt den Punkt "'''Installation'''" aus
* Anschließend wählt man die Sprache und bestätigt die Lizenzinformationen
* Nun wird man gefragt, was man tun möchte: "Neuinstallation", "Aktualisieren" oder "Weitere Optionen"
** An dieser Stelle wählt man den Punkt "'''Weitere Optionen'''"
** Nun markiert man noch "'''Reparatur des installierten Systems'''"
* Mit den jetzt erscheinenden Reparaturwerkzeugen hat man nun die Möglichkeit, den Bootloader GRUB neu zu installieren
** Der Punkt "'''Expertenwerkzeuge'''" hält hierbei ein spezielles Werkzeug "'''Neuen Bootloader installieren'''" bereit
Bei [[OpenSUSE]] 11.3 gibt es "'''Reparatur des installierten Systems'''" nicht mehr.

== GRUB wiederherstellen unter [[Ubuntu|Ubuntu/Kubuntu]] ==
* [http://wiki.ubuntuusers.de/GRUB#Bootloader Anleitung zur Wiederherstellung des Bootloaders aus dem Wiki von Ubuntuusers]

== Weitere Wege der Wiederherstellung/Installation von GRUB ==
* [[Grub-Install via "chroot" und Knoppix|In diesem Artikel hier im Wiki wird erklärt, wie man GRUB mittels einer Knoppix CD installieren kann.]] Dieser Artikel gilt nicht für openSUSE, da eine andere Version des Programms grub-install verwendet wird.

----
[[Bootmanager|Zurück zur Bootmanager-Übersicht]]
[[Category:Bootmanager]]

Runlevel scripte - Scripts selbst erstellen

2010-11-23T21:59:07Z

Josef-wien: Der letzte Absatz (Durchführung und Abhängigkeiten) wurde hinzugefügt.

Wer einen eigenen Dienst in den [[Bootvorgang|Boot-Ablauf]] einhängen möchte, kann das nach folgendem Bauplan tun: In

cd /etc/init.d
wird ein beliebiges Script (oder skeleton) kopiert. Es gibt im Internet und in entsprechenden Foren schon vorgefertigte Scripte für allerlei Einsatzzwecke.

Diese Sektion muss noch angepasst werden (das Beispiel ist von named):

### BEGIN INIT INFO
# Provides: named
# Required-Start: $network $remote_fs $syslog
# Required-Stop:
# Default-Start: 3 5
# Default-Stop:
# Description: Starts internet domain name server (DNS) BIND 9
### END INIT INFO
Zur Erklärung der einzelnen Zeilen:
Provides: <== der Name des Dienstes
Required-Start: <== Liste der Dienste die VOR dem erstellten Dienst gestartet werden müssen
Default-Start: <== Liste der Runlevel, in denen der Dienst gestartet wird
Description: <== kurze Beschreibung des Dienstes
Danach muss das Script auch ausführbar gemacht werden, damit es auch gestartet werden kann. Das erreicht man mit:
chmod +x meinScript
Wenn dieses Attribut gesetzt ist, muss es auch noch aktiviert werden:
insserv meinScript
Diesen Schritt kann man auch über Yast -> System -> Runlevel-Editor vollziehen.

Damit das Script auch aufgerufen werden kann, muss man noch den openSUSE-spezifischen Link erstellen:
cd /usr/sbin oder cd /sbin
ln -s /etc/init.d/meinScript rcmeinScript

Den Test, ob das Script startet und funktioniert, kann man mit diesen beiden Befehlen machen:
rcmeinScript start
rcmeinScript stop
Der erste startet, der zweite stoppt das Script.

Weitere Dokumentation findet man mit:
man init
TIP:
Mit dem Befehl
rc_status -v
kann DONE, FAILED, SKIPPED etc. ausgegeben werden.
Wenn die Zeile der Ausgabe nicht stimmt, probiere
rc_status -v2
damit wird die Ausgabe zwei Zeilen höher ausgegeben.

Für die Durchführung und die Abhängigkeiten der Scripte sind bei openSUSE die Eintragungen in den vier Dateien /etc/init.d/.depend.* maßgeblich, die von insserv aktuell gehalten werden. Die Nummern für die in /etc/init.d/*.d/ angelegten Verknüpfungen sind nur mehr eine Verbeugung an die Vergangenheit (mit ihrem sequentiellen und damit langsamen Abarbeiten der Scripte), das manuelle Erstellen einer solchen Verknüpfung nützt daher nichts.

[[Kategorie:Allgemeines]]
[[Kategorie:Programmierung]]

Partition

2010-06-17T20:20:22Z

Josef-wien: Überschrift "NonRaid ..." angepaßt

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]] bis 11.2
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle sichern und wiederherstellen]]
* [[Verlorene Dateien wiederherstellen ext3 ext4|Gelöschte Dateien wiederherstellen ext3/ext4]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

NonRaid zu (software)Raid1 SuSE 10 1

2010-06-17T20:17:45Z

Josef-wien: Dateiname device.map richtiggestellt

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein [[RAID allgemein#Softwareraid|Software-RAID]] zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.

{{Box Test||
* SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos 
* open SUSE 10.2 Prinzipielles Funktionieren des Howto 
* open SUSE 10.3 Änderungen und Ergänzungen führten zur aktuellen Version 
* open SUSE 11.0 Prinzipielles Funktionieren des Howto 
* open SUSE 11.1 Kurztest
* open SUSE 11.2 Test und ein paar kleinere Updates
}}

{{ Box Hinweis||Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können.
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die '''fstab''' und GRUBs '''menu.lst'''. Erfahrungen mit '''mdadm''' können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: '''dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammelt haben''' }}

== Konfiguration des Ausgangssystems ==

Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :
automat:/proc # fdisk -l

Disk /dev/sda: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 65 66544 83 Linux
/dev/sda2 66 5186 5243904 83 Linux
/dev/sda3 5187 25667 20972544 83 Linux
/dev/sda4 25668 35003 9560064 f W95 Ext'd (LBA)
/dev/sda5 25668 27716 2098160 82 Linux swap / Solaris
/dev/sda6 27717 35003 7461872 83 Linux

Disk /dev/sdb: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 35003 35843056 83 Linux

automat:/proc # cat /etc/fstab
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda5 swap swap pri=42 0 0
/dev/sda1 /boot ext2 acl,user_xattr 1 2
/dev/sda3 /home ext3 acl,user_xattr 1 2
/dev/sda6 /data ext2 auto,ro 1 2
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
sysfs /sys sysfs noauto 0 0
/dev/fd0 /media/floppy auto noauto,user,sync 0 0

Es gibt also zwei gleiche Platten, wovon '''sdb''' derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( '''/home''' , ''' /data''' ), auch ''' /boot ''' ist ein separates Filesystem.

{{Box Hinweis||Das Howto ist so geschrieben, dass es egal ist, ob das '''/boot-Verzeichnis''' auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen}}

== Anlegen einer identischen Partitionstabelle ==

Zuerst klonen wir die gesamte Partionstabelle von '''sda''' nach '''sdb''':

automat:/proc # sfdisk -d /dev/sda > /tmp/sda.txt
automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sdb1 0+ 35002 35003- 35843056 83 Linux
/dev/sdb2 0 - 0 0 0 Empty
/dev/sdb3 0 - 0 0 0 Empty
/dev/sdb4 0 - 0 0 0 Empty
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 * 32 133119 133088 83 Linux
/dev/sdb2 133120 10620927 10487808 83 Linux
/dev/sdb3 10620928 52566015 41945088 83 Linux
/dev/sdb4 52566016 71686143 19120128 f W95 Ext'd (LBA)
/dev/sdb5 52566048 56762367 4196320 82 Linux swap / Solaris
/dev/sdb6 56762400 71686143 14923744 83 Linux
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
'''fdisk -l''' zeigt nun, dass alle Partitionen auf '''sda''' und '''sdb''' gleich sind. Da '''sdb''' z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen. 
In diesem Fall die Option '''--force''' probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigenem Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte [[Partitionstabelle sichern und wiederherstellen|hier]] nachlesen.

== Raid für das zukünftige Rootfilesystem erstellen ==

Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
'''sda''' wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.
{{OpenSUSE|10.3|
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.

Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird, reicht folgender Befehl
ls /etc/init.d/boot.d/*boot.md
kommt hier als Antwort
ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.
insserv /etc/init.d/boot.md
}}

So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit '''sdb2''' als einziger aktive Komponente.
Zunächst wird die Partitions-ID von '''sdb2''' geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon, aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''

automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Done
automat:/proc # sfdisk -R /dev/sdb

Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
Das wird unser zukünftiges Rootfilesystem aufnehmen.

automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
mdadm: /dev/sdb2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
Continue creating array? y
mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

und/oder

automat:/proc # mdadm -D /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Sat Aug 19 21:27:47 2006
Raid Level : raid1
Array Size : 5243840 (5.00 GiB 5.37 GB)
Device Size : 5243840 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Aug 19 21:27:47 2006
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
Events : 0.1

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 18 1 active sync /dev/sdb2

Wir tragen jetzt unser konfiguriertes RAID-Device in die '''mdadm.conf''' ein. Es ist erforderlich, eine DEVICES-Zeile in '''mdadm.conf''' einzufügen (sofern dies noch nicht geschehen ist), damit [http://linux.die.net/man/8/mdadm mdadm] beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in '''mdadm.conf''' ein:

automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
automat:/ # cat /etc/mdadm.conf
DEVICE /dev/sd[a-z][0-9]
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf '''/dev/md0''' anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.

automat:/ # mkfs.ext3 -j /dev/md0
...
...
automat:/ # mount /dev/md0 /mnt
automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei '''/mnt/''' ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von [http://linux.die.net/man/1/rsync rsync] gegenüber anderen Programmen ist ACLs (''' -A ''') und Xattrs (''' -X ''') übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option ''' -A ''' ist vor SUSE Linux 10.1 nicht vorhanden; die Option ''' -X ''' nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich ''' --delete-during ''' (sollte die Option nicht bekannt sein, ist auf ''' --delete ''' auszuweichen) aufzurufen.

Jetzt ändern wir auf dem "neuem" Rootfilesystem die '''etc/fstab'''

automat:/ # cd /mnt/etc
automat:/mnt/etc # vi fstab
/dev/sda2 / ext3 acl,user_xattr 1 1 (dieses ist der alte Zeile)
/dev/md0 / ext3 acl,user_xattr 1 1 (das ist geänderte Zeile)

{{OpenSUSE|10.3|
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.

erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid
<pre>
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 / ext3 acl,user_xattr 1 1
/dev/md0 / ext3 acl,user_xattr 1 1
</pre>
}}

Das Filesystem wird dann wieder umount'ed und die '''/boot/grub/menu.lst''' angepasst:

automat:/mnt/etc # cd /
automat:/ # umount /mnt
automat:/ # cd /boot/grub
automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das '''root=''' Argument so, dass nun '''md0''' als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:

#(normaler Booteintrag bleibt stehen)
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd
#(nachfolgender Booteintrag kommt neu hinzu)
#--------- RAID----------#
title SUSE RAID 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd

{{OpenSUSE|10.3|
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.

<pre>
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>
}}

Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus '''mdadm.conf''' und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von '''mkinitrd''' automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0

automat:/ # mkinitrd -f md -d /dev/md0

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.

'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.

== Anlegen der restlichen Raiddevices ==

Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
/dev/sda6 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher.
Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne '''sda''' zu verändern.

{{Kasten rot|Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.}}

Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

sfdisk --change-id /dev/sdb 1 fd
sfdisk --change-id /dev/sdb 3 fd
sfdisk --change-id /dev/sdb 5 fd
sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2 missing /dev/sdb1
mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2 missing /dev/sdb5
mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2 missing /dev/sdb3
mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2 missing /dev/sdb6

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md4 : active raid1 sdb6[1]
7461760 blocks [2/1] [_U]

md3 : active raid1 sdb3[1]
20972480 blocks [2/1] [_U]

md2 : active raid1 sdb5[1]
2098048 blocks [2/1] [_U]

md1 : active raid1 sdb1[1]
66432 blocks [2/1] [_U]

md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Danach müssen die neuen RAID-Devices in der '''mdadm.conf''' eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Notiz-Zettel hilft hier sicher ;-)''

'''Zwischenbemerkung:''' Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem" neu anlegen.

mkswap /dev/md2
mkfs.ext2 /dev/md1
mkfs.ext3 -j /dev/md3
mkfs.ext2 /dev/md4

Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von [http://linux.die.net/man/1/cp cp], über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird [http://www.bellevuelinux.org/man/cpio.1.html cpio] dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein. 
{{blau|; Man kann sich etwa an folgendem orientieren:
wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als '''cpio''' nehmen sollte. Dann könnte man hier zB mit [http://linux.die.net/man/1/rsync rsync] ( schon oben beim kopieren der Rootpartition beschrieben) oder mit [http://linux.die.net/man/1/star star] und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein '''tar''' als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.}}

automat:/ # mount /dev/md1 /mnt
automat:/ # cd /boot
automat:/boot # find . -mount | cpio -pdumC65536 /mnt
349 blocks
automat:/boot # umount /mnt
automat:/boot # mount /dev/md3 /mnt
automat:/boot # cd /home
automat:/home # find . -mount | cpio -pdumC65536 /mnt
53011 blocks
automat:/home # umount /mnt
automat:/home # mount /dev/md4 /mnt
automat:/home # cd /data
automat:/data # find . -mount | cpio -pdumC65536 /mnt
52731 blocks

Natürlich ist jetzt noch die '''/etc/fstab''' anzupassen:
''bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht''

automat:/data # cat /etc/fstab
/dev/md0 / ext3 acl,user_xattr 1 1
/dev/md2 swap swap pri=42 0 0
/dev/md1 /boot ext2 acl,user_xattr 1 2
/dev/md3 /home ext3 acl,user_xattr 1 2
/dev/md4 /data ext2 auto,ro 1 2
.....

'''2. Teil fertig:''' An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem '''/boot'''. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.

== Prüfen des Systems vor dem entgültigen Spiegeln ==

Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

automat:~ # swapon -s
Filename Type Size Used Priority
/dev/md2 partition 2098040 0 42
automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md1 on /boot type ext2 (rw,acl,user_xattr)
/dev/md3 on /home type ext3 (rw,acl,user_xattr)
/dev/md4 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von [http://linux.die.net/man/8/swapon swapon] als auch von [http://linux.die.net/man/8/mount mount] sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,

{{Box Achtung||'''wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen''', ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.}}

Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:
* bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
* ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
* die initrd wurde neu erstellt und hat jetzt Raidsupport
alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.

== Herstellung der Spiegelung ==

Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

{{Box Achtung||'''Ab hier wird das alte System nicht mehr bootfähig.'''}}

sfdisk --change-id /dev/sda 1 fd
sfdisk --change-id /dev/sda 2 fd
sfdisk --change-id /dev/sda 3 fd
sfdisk --change-id /dev/sda 5 fd
sfdisk --change-id /dev/sda 6 fd

mdadm /dev/md4 -a /dev/sda6
mdadm /dev/md3 -a /dev/sda3
mdadm /dev/md2 -a /dev/sda5
mdadm /dev/md1 -a /dev/sda1
mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md1 : active raid1 sda1[0] sdb1[1]
66432 blocks [2/2] [UU]

md3 : active raid1 sda3[0] sdb3[1]
20972480 blocks [2/1] [_U]
[==>..................] recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec

md4 : active raid1 sda6[0] sdb6[1]
7461760 blocks [2/2] [UU]

md2 : active raid1 sda5[0] sdb5[1]
2098048 blocks [2/1] [_U]
resync=DELAYED

md0 : active raid1 sda2[2] sdb2[1]
5243840 blocks [2/1] [_U]
resync=DELAYED

unused devices: <none>

{{Box Achtung||
Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten}}

== Konfiguration von Grub ==

=== Konfiguration von /boot/grub/menu.lst ===

Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die '''/boot/grub/menu.lst'''.
Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.
root=
resume=
dort sollte überall jetzt ein /dev/md? stehen.

Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen '''(hd?,?)''' Einträgen. Zur Sicherheit geben wir die '''Kernel''' und die '''initrd''' mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für '''Kernel''' und '''initrd''' nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.

{{blau|man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB
kann die Platten nur einzeln sehen.}}

Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über [[Grub]] gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht.

So hier sollten diese Booteinträge nach der Änderung dann aussehen: (''' man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt''' 
(''ich habe [http://wiki.linux-club.de/opensuse/Diskussion:NonRaid_zu_%28software%29Raid1_SuSE_10_1#Beispiel_einer_menu.lst_bei_openSUSE_10.3 hier] auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.'')

automat:/boot/grub # vi menu.lst
# Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
color white/blue black/light-gray
default 0
fallback 1
timeout 8
gfxmenu (hd0,0)/message

#--------- RAID----------#
title SUSE RAID 10.1 1-Platte
root (hd0,0)
kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd0,0)/initrd

#--------- RAID----------#
title SUSE RAID 10.1 2-Platte
root (hd1,0)
kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd1,0)/initrd

=== Erzeugen der Bootloader im MBR auf beiden Spiegelplatten ===

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei [[Grub]] vorbeischauen.
; root (hd1,0) : bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der '''Partition 1''' der Platte die in '''/boot/grub/device.map''' als '''hd1''' geführt wird
; setup (hd1) : und werden konfiguriert für den MBR eben dieser Platte '''hd1'''.
und das Ganze konfigurieren wir für beide Platten.

automat:/boot/grub # grub

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

== Aufnahme der neuen Platte in die /boot/grub/device.map ==

Bislang steht in der Datei nur

(fd0) /dev/fd0
(hd0) /dev/sda

Die folgenden Zeile muss noch zugefügt werden.

(hd1) /dev/sdb

== Abschließende Konfiguration ==

Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der '''initrd''' bekannt sind.

automat:/boot/grub # mkinitrd -f md

Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ('''faulty''') geht: an das Ende der '''mdadm.conf''' fügen wir unsere Mailaddresse ein.
echo "MAILADDR root@localhost" >> /etc/mdadm.conf

Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den '''mdadmd-Deamon''' starten, entweder über YaST oder mittels '''insserv'''
insserv /etc/init.d/mdadmd

'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im BIOS auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.

== weitere Optionale Konfigurationen ==

{{openSUSE|10.3|Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der '''/etc/fstab''' und in der '''/boot/grub/menu.lst''' die Einträge manuell wieder auf DISK-BY-ID umstellen,
die genauen Werte die zu benutzen sind kann man zB mit:
ls -l /dev/disk/by-id/md-uuid*
abfragen. ''( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)'' }}

Wer ganz sicher gehen will trägt noch das Raidmodul in die '''/etc/sysconfig/kernel''' in die Zeile '''INITRD_MODULES=''' ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von '''mkinitrd''' das Rootdevice ein Raid ist, wird [http://linux.die.net/man/8/mkinitrd mkinitrd] das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.

[[Category:Partitionen]]

Partition

2009-11-14T17:19:46Z

Josef-wien:

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]] bis 11.1
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle sichern und wiederherstellen]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

NonRaid zu (software)Raid1 SuSE 10 1

2009-11-14T17:10:01Z

Josef-wien: "getestet mit" ergänzt um 11.0 und 11.1

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein [[RAID allgemein#Softwareraid|Software-RAID]] zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.

{{Box Test||
* SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos 
* open SUSE 10.2 Prinzipielles Funktionieren des Howto 
* open SUSE 10.3 Änderungen und Ergänzungen führten zur aktuellen Version 
* open SUSE 11.0 Prinzipielles Funktionieren des Howto 
* open SUSE 11.1 Kurztest
}}

{{ Box Hinweis||Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können.
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die '''fstab''' und GRUBs '''menu.lst'''. Erfahrungen mit '''mdadm''' können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: '''dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammtelt haben''' }}

== Konfiguration des Ausgangssystems ==

Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :
automat:/proc # fdisk -l

Disk /dev/sda: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 65 66544 83 Linux
/dev/sda2 66 5186 5243904 83 Linux
/dev/sda3 5187 25667 20972544 83 Linux
/dev/sda4 25668 35003 9560064 f W95 Ext'd (LBA)
/dev/sda5 25668 27716 2098160 82 Linux swap / Solaris
/dev/sda6 27717 35003 7461872 83 Linux

Disk /dev/sdb: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 35003 35843056 83 Linux

automat:/proc # cat /etc/fstab
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda5 swap swap pri=42 0 0
/dev/sda1 /boot ext2 acl,user_xattr 1 2
/dev/sda3 /home ext3 acl,user_xattr 1 2
/dev/sda6 /data ext2 auto,ro 1 2
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
sysfs /sys sysfs noauto 0 0
/dev/fd0 /media/floppy auto noauto,user,sync 0 0

Es gibt also zwei gleiche Platten, wovon '''sdb''' derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( '''/home''' , ''' /data''' ), auch ''' /boot ''' ist ein separates Filesystem.

{{Box Hinweis||Das Howto ist so geschrieben, dass es egal ist, ob das '''/boot-Verzeichnis''' auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen}}

== Anlegen einer identischen Partitionstabelle ==

Zuerst klonen wir die gesamte Partionstabelle von '''sda''' nach '''sdb''':

automat:/proc # sfdisk -d /dev/sda > /tmp/sda.txt
automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sdb1 0+ 35002 35003- 35843056 83 Linux
/dev/sdb2 0 - 0 0 0 Empty
/dev/sdb3 0 - 0 0 0 Empty
/dev/sdb4 0 - 0 0 0 Empty
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 * 32 133119 133088 83 Linux
/dev/sdb2 133120 10620927 10487808 83 Linux
/dev/sdb3 10620928 52566015 41945088 83 Linux
/dev/sdb4 52566016 71686143 19120128 f W95 Ext'd (LBA)
/dev/sdb5 52566048 56762367 4196320 82 Linux swap / Solaris
/dev/sdb6 56762400 71686143 14923744 83 Linux
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
'''fdisk -l''' zeigt nun, dass alle Partitionen auf '''sda''' und '''sdb''' gleich sind. Da '''sdb''' z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen. 
In diesem Fall die Option '''--force''' probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigenem Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte [[Partitionstabelle sichern und wiederherstellen|hier]] nachlesen.

== Raid für das zukünftige Rootfilesystem erstellen ==

Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
'''sda''' wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.
{{OpenSUSE|10.3|
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.

Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird, reicht folgender Befehl
ls /etc/init.d/boot.d/*boot.md
kommt hier als Antwort
ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.
insserv /etc/init.d/boot.md
}}

So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit '''sdb2''' als einziger aktive Komponente.
Zunächst wird die Partitions-ID von '''sdb2''' geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon, aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''

automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Done
automat:/proc # sfdisk -R /dev/sdb

Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
Das wird unser zukünftiges Rootfilesystem aufnehmen.

automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
mdadm: /dev/sdb2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
Continue creating array? y
mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

und/oder

automat:/proc # mdadm -D /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Sat Aug 19 21:27:47 2006
Raid Level : raid1
Array Size : 5243840 (5.00 GiB 5.37 GB)
Device Size : 5243840 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Aug 19 21:27:47 2006
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
Events : 0.1

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 18 1 active sync /dev/sdb2

Wir tragen jetzt unser konfiguriertes RAID-Device in die '''mdadm.conf''' ein. Es ist erforderlich, eine DEVICES-Zeile in '''mdadm.conf''' einzufügen (sofern dies noch nicht geschehen ist), damit [http://linux.die.net/man/8/mdadm mdadm] beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in '''mdadm.conf''' ein:

automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
automat:/ # cat /etc/mdadm.conf
DEVICE /dev/sd[a-z][0-9]
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf '''/dev/md0''' anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.

automat:/ # mkfs.ext3 -j /dev/md0
...
...
automat:/ # mount /dev/md0 /mnt
automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei '''/mnt/''' ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von [http://linux.die.net/man/1/rsync rsync] gegenüber anderen Programmen ist ACLs (''' -A ''') und Xattrs (''' -X ''') übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option ''' -A ''' ist vor SUSE Linux 10.1 nicht vorhanden; die Option ''' -X ''' nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich ''' --delete-during ''' (sollte die Option nicht bekannt sein, ist auf ''' --delete ''' auszuweichen) aufzurufen.

Jetzt ändern wir auf dem "neuem" Rootfilesystem die '''etc/fstab'''

automat:/ # cd /mnt/etc
automat:/mnt/etc # vi fstab
/dev/sda2 / ext3 acl,user_xattr 1 1 (dieses ist der alte Zeile)
/dev/md0 / ext3 acl,user_xattr 1 1 (das ist geänderte Zeile)

{{OpenSUSE|10.3|
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.

erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid
<pre>
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 / ext3 acl,user_xattr 1 1
/dev/md0 / ext3 acl,user_xattr 1 1
</pre>
}}

Das Filesystem wird dann wieder umount'ed und die '''/boot/grub/menu.lst''' angepasst:

automat:/mnt/etc # cd /
automat:/ # umount /mnt
automat:/ # cd /boot/grub
automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das '''root=''' Argument so, dass nun '''md0''' als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:

#(normaler Booteintrag bleibt stehen)
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd
#(nachfolgender Booteintrag kommt neu hinzu)
#--------- RAID----------#
title SUSE RAID 10.1
root (hd0,0)
kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent showopts
initrd /initrd

{{OpenSUSE|10.3|
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.

<pre>
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>
}}

Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus '''mdadm.conf''' und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von '''mkinitrd''' automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0

automat:/ # mkinitrd -f md -d /dev/md0

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.

'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.

== Anlegen der restlichen Raiddevices ==

Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
/dev/sda6 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher.
Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne '''sda''' zu verändern.

{{Kasten rot|Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.}}

Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

sfdisk --change-id /dev/sdb 1 fd
sfdisk --change-id /dev/sdb 3 fd
sfdisk --change-id /dev/sdb 5 fd
sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2 missing /dev/sdb1
mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2 missing /dev/sdb5
mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2 missing /dev/sdb3
mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2 missing /dev/sdb6

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md4 : active raid1 sdb6[1]
7461760 blocks [2/1] [_U]

md3 : active raid1 sdb3[1]
20972480 blocks [2/1] [_U]

md2 : active raid1 sdb5[1]
2098048 blocks [2/1] [_U]

md1 : active raid1 sdb1[1]
66432 blocks [2/1] [_U]

md0 : active raid1 sdb2[1]
5243840 blocks [2/1] [_U]

unused devices: <none>

Danach müssen die neuen RAID-Devices in der '''mdadm.conf''' eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Notiz-Zettel hilft hier sicher ;-)''

'''Zwischenbemerkung:''' Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem" neu anlegen.

mkswap /dev/md2
mkfs.ext2 /dev/md1
mkfs.ext3 -j /dev/md3
mkfs.ext2 /dev/md4

Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von [http://linux.die.net/man/1/cp cp], über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird [http://www.bellevuelinux.org/man/cpio.1.html cpio] dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein. 
{{blau|; Man kann sich etwa an folgendem orientieren:
wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als '''cpio''' nehmen sollte. Dann könnte man hier zB mit [http://linux.die.net/man/1/rsync rsync] ( schon oben beim kopieren der Rootpartition beschrieben) oder mit [http://linux.die.net/man/1/star star] und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein '''tar''' als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.}}

automat:/ # mount /dev/md1 /mnt
automat:/ # cd /boot
automat:/boot # find . -mount | cpio -pdumC65536 /mnt
349 blocks
automat:/boot # umount /mnt
automat:/boot # mount /dev/md3 /mnt
automat:/boot # cd /home
automat:/home # find . -mount | cpio -pdumC65536 /mnt
53011 blocks
automat:/home # umount /mnt
automat:/home # mount /dev/md4 /mnt
automat:/home # cd /data
automat:/data # find . -mount | cpio -pdumC65536 /mnt
52731 blocks

Natürlich ist jetzt noch die '''/etc/fstab''' anzupassen:
''bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht''

automat:/data # cat /etc/fstab
/dev/md0 / ext3 acl,user_xattr 1 1
/dev/md2 swap swap pri=42 0 0
/dev/md1 /boot ext2 acl,user_xattr 1 2
/dev/md3 /home ext3 acl,user_xattr 1 2
/dev/md4 /data ext2 auto,ro 1 2
.....

'''2. Teil fertig:''' An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem '''/boot'''. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.

== Prüfen des Systems vor dem entgültigen Spiegeln ==

Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

automat:~ # swapon -s
Filename Type Size Used Priority
/dev/md2 partition 2098040 0 42
automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md1 on /boot type ext2 (rw,acl,user_xattr)
/dev/md3 on /home type ext3 (rw,acl,user_xattr)
/dev/md4 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von [http://linux.die.net/man/8/swapon swapon] als auch von [http://linux.die.net/man/8/mount mount] sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,

{{Box Achtung||'''wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen''', ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.}}

Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:
* bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
* ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
* die initrd wurde neu erstellt und hat jetzt Raidsupport
alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.

== Herstellung der Spiegelung ==

Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

{{Box Achtung||'''Ab hier wird das alte System nicht mehr bootfähig.'''}}

sfdisk --change-id /dev/sda 1 fd
sfdisk --change-id /dev/sda 2 fd
sfdisk --change-id /dev/sda 3 fd
sfdisk --change-id /dev/sda 5 fd
sfdisk --change-id /dev/sda 6 fd

mdadm /dev/md4 -a /dev/sda6
mdadm /dev/md3 -a /dev/sda3
mdadm /dev/md2 -a /dev/sda5
mdadm /dev/md1 -a /dev/sda1
mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md1 : active raid1 sda1[0] sdb1[1]
66432 blocks [2/2] [UU]

md3 : active raid1 sda3[0] sdb3[1]
20972480 blocks [2/1] [_U]
[==>..................] recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec

md4 : active raid1 sda6[0] sdb6[1]
7461760 blocks [2/2] [UU]

md2 : active raid1 sda5[0] sdb5[1]
2098048 blocks [2/1] [_U]
resync=DELAYED

md0 : active raid1 sda2[2] sdb2[1]
5243840 blocks [2/1] [_U]
resync=DELAYED

unused devices: <none>

{{Box Achtung||
Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten}}

== Konfiguration von Grub ==

=== Konfiguration von /boot/grub/menu.lst ===

Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die '''/boot/grub/menu.lst'''.
Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.
root=
resume=
dort sollte überall jetzt ein /dev/md? stehen.

Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen '''(hd?,?)''' Einträgen. Zur Sicherheit geben wir die '''Kernel''' und die '''initrd''' mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für '''Kernel''' und '''initrd''' nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.

{{blau|man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB
kann die Platten nur einzeln sehen.}}

Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über [[Grub]] gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht.

So hier sollten diese Booteinträge nach der Änderung dann aussehen: (''' man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt''' 
(''ich habe [http://wiki.linux-club.de/opensuse/Diskussion:NonRaid_zu_%28software%29Raid1_SuSE_10_1#Beispiel_einer_menu.lst_bei_openSUSE_10.3 hier] auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.'')

automat:/boot/grub # vi menu.lst
# Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
color white/blue black/light-gray
default 0
fallback 1
timeout 8
gfxmenu (hd0,0)/message

#--------- RAID----------#
title SUSE RAID 10.1 1-Platte
root (hd0,0)
kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd0,0)/initrd

#--------- RAID----------#
title SUSE RAID 10.1 2-Platte
root (hd1,0)
kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent showopts
initrd (hd1,0)/initrd

=== Erzeugen der Bootloader im MBR auf beiden Spiegelplatten ===

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei [[Grub]] vorbeischauen.
; root (hd1,0) : bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der '''Partition 1''' der Platte die in '''/boot/grub/device.map''' als '''hd1''' geführt wird
; setup (hd1) : und werden konfiguriert für den MBR eben dieser Platte '''hd1'''.
und das Ganze konfigurieren wir für beide Platten.

automat:/boot/grub # grub

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

== Abschließende Konfiguration ==

Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der '''initrd''' bekannt sind.

automat:/boot/grub # mkinitrd -f md

Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ('''faulty''') geht: an das Ende der '''mdadm.conf''' fügen wir unsere Mailaddresse ein.
echo "MAILADDR root@localhost" >> /etc/mdadm.conf

Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den '''mdadmd-Deamon''' starten, entweder über YaST oder mittels '''insserv'''
insserv /etc/init.d/mdadmd

'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im BIOS auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.

== weitere Optionale Konfigurationen ==

{{openSUSE|10.3|Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der '''/etc/fstab''' und in der '''/boot/grub/menu.lst''' die Einträge manuell wieder auf DISK-BY-ID umstellen,
die genauen Werte die zu benutzen sind kann man zB mit:
ls -l /dev/disk/by-id/md-uuid*
abfragen. ''( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)'' }}

Wer ganz sicher gehen will trägt noch das Raidmodul in die '''/etc/sysconfig/kernel''' in die Zeile '''INITRD_MODULES=''' ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von '''mkinitrd''' das Rootdevice ein Raid ist, wird [http://linux.die.net/man/8/mkinitrd mkinitrd] das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.

[[Category:Partitionen]]

Bootmanager

2009-09-09T21:38:17Z

Josef-wien: 8. und 9. Unterpunkt von GRUB standen bisher unter "Vista ..."

== Bootloader ==
* [[GRUB]]
** [[GRUB wiederherstellen]]
** [[von Grub direkt auf CD-Boot umschwenken]]
** [[Grub-Install via "chroot" und Knoppix]]
** [[Grub, Raid1 Ausfallsicherheit]]
** [[Grub ERROR]]
** [[SuSE_und_Grub]] Zusammenspiel und Probleme - Yast-Bootloaderkonfiguration und Grub
** [[Linux booten via Grub-Shell]]
** [[Beim reboot das zu startende Betriebssystem auswählen]]
** [[GRUB Musterkonfigurationen]]
* [[o:SDB:Windows von der zweiten Festplatte booten]]
* [[o:SDB:Mehrere Windows-Installationen von einer Festplatte booten]]
* [[o:SDB:Linux mit Hilfe des Bootmanagers von Windows NT/2000/XP booten]]
* [[o:SDB:Passwort setzen für den Bootmanager GRUB]]
* [[o:SDB:Per GRUB über Netzwerk booten]]
* [http://www.linux-user.de/ausgabe/2007/04/030-vista-dualboot/index.html Vista-Bootloader für Linux einrichten]
* [[LILO]]
* [[Lilo wieder herstellen]] Den Bootloader LILO mit Hilfe einer Live-CD wiederherstellen.
* [[Installationsbootloader]] - Bootloader mit Schwerpunkt Systeminstallation. Diverse Bootloader, deren Schwerpunkt die Betriebssysteminstallation ist, die jedoch auch für Rescuesysteme, Servicetools und generellem Systemstart genutzt werden können(auch um über das Netzwerk zu booten).

== Verschiedenes ==
* [[Linkliste#FAQ_Kernel-_.2F_Bootparameter|FAQ Kernel/Bootparameter]] - Linkliste
* [[Splash Screen]] - Erstellen eines Splash Screens
* [[openSUSE automatisch herunterfahren lassen]]
* [[ReiserFS]]
* [[Disk Quota]] - Disk Quota auf Filesystemen einrichten
* [[Bootverzögerungen durch fsck]] - automatischen Filesystemcheck bei ext3 optimieren
* [[Windows auf Linux-PC installieren]] - Setup-Menü der Windows-Install-CD erscheint nicht

== Quellen und weiterführende Links ==

=== Artikel aus der SDB zu SuSE 9.3 ===

* [[o:SDB:Installation bleibt stehen oder findet keine Festplatten|Installation bleibt stehen oder findet keine Festplatten]]
* [[o:SDB:Nach Update von 9.2 auf 9.3 wird als Loginmanager XDM verwendet|Nach Update von 9.2 auf 9.3 wird als Loginmanager XDM verwendet]]
* [[o:SDB:Klassisch mounten statt subfs|Klassisch mounten statt subfs]]
* [[o:SDB:Mounten zu festen Mountpoints|Mounten zu festen Mountpoints]]

----

[[Hauptseite|zurück zur Hauptseite]]

[[Category:Bootmanager]]

Zwei Kernel parallel installieren

2009-07-25T22:19:03Z

Josef-wien: Eine Anmerkung zur Anzahl der *.rpm-Dateien wurde eingefügt.

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln. D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

Bis openSUSE 11.0 besteht der kompilierte Kernel aus einer *.rpm-Datei. Bei openSUSE 11.1 sind es mit Ausnahme des Vanilla-Kernel drei *.rpm-Dateien (kernel-xxx, kernel-xxx-base und kernel-xxx-extra, xxx steht für den Kernel-Typ, z.B. default), die als Einheit betrachtet werden sollen. Die Datei kernel-xxx-extra sollte nur dann weggelassen werden, wenn man ganz sicher ist, diese Module nicht zu benötigen.

== Erste Variante ==

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

== Zweite Variante ==

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Wichtig ist, zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Neuere openSUSE-Versionen schreiben nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>, daher muss zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

Zwei Kernel parallel installieren

2009-07-24T21:49:40Z

Josef-wien: Ergänzungen betreffend openSUSE 11.x, Löschung des doppelt vorhandenen ersten Satzes.

{{Box Test||
* [[openSUSE]] 10.2, 11.0, 11.1
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln.
D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

== Erste Variante ==

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

== Zweite Variante ==

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser Verzeichnis <code>/boot</code> sollte nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Wichtig ist, zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>.

Bei älteren (open)SUSE-Versionen wird die Verknüpfung verwendet, daher ist der Eintrag für den neuen Kernel (<code>vmlinuz</code>) in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten. Damit unser alter Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden. Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Neuere openSUSE-Versionen schreiben nicht die Verknüpfung, sondern den vollständigen Dateinamen in die <code>/boot/grub/menu.lst</code>, daher muss zusätzlich zum vorhandenen Eintrag für den alten Kernel ein Eintrag für den neuen Kernel erstellt werden.

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den Kernel "SuSE-default" in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

Zwei Kernel parallel installieren

2009-07-24T21:20:42Z

Josef-wien: Die Überschrift "Das Verzeichnis /boot" wurde eingefügt, da der Text ab hier für beide Varianten gilt.

{{Box Test||
* [[openSUSE]] 10.2
* SUSE Linux 10.0
* SUSE Linux 9.3
}}
Autor: oc2pus

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln.

Um mal mit einem kernel-of-the-day oder einem selbsterstellten Kernel rumzuspielen, sollte man sich einen kleinen Rettungsanker basteln.
D.h. man hat mehrere Kernel zur Auswahl und kann im Falle eines Falles einen funktionsfähigen Kernel zum Booten verwenden.

== Erste Variante ==

Am einfachsten geht es, indem man ohne "den alten ohne Anker aus der rpm-db rauszuwerfen" (<code>--justdb</code> in der zweiten Variante), und einfach den neuen gewünschten Kernel installiert (Tip von j.engelh):

rpm -ihv kernel-default-2.6.18.6-jen43.i586.rpm

Wenn dieser Kernel beim nächsten Reboot funktioniert, dann kann man den anderen Kernel mit folgendem Befehl entfernen:

rpm -e kernel-default-2.6.18.2-34

Und wer seinen Kernel selbst kompilieren will, der sollte sich das hervorragende HOWTO von [[Benutzer:gimpel|gimpel]] anschauen:
* [[Kernelbau]]

== Zweite Variante ==

Dazu wird zunächst der aktuelle Kernel aus der RPM-Datenbank entfernt.

rpm -e --justdb kernel-default

Die Dateien und Module des Kernels bleiben auf der Festplatte, nur der Datenbankeintrag verschwindet!
Dies ist erforderlich, da sonst bei einem Kernel-Update genau dieses Dateien gelöscht würden und der neue Kernel installiert würde. Allerdings muss man den alten Kernel dann auch von Hand entfernen, wenn man diesen nicht mehr benötigt.

Nehmen wir an unser aktueller Kernel sei <code>kernel-2.6.5-7.104-default</code>.
Da wir jetzt keinen RPM-Datenbank Eintrag mehr besitzen, können wir den neuen Kernel installieren. Entweder mit apt oder YaST oder via Kommandozeilen-Befehl <code>rpm -i kernel-default-2.6.x-y-default.i586.rpm</code>.

== Das Verzeichnis /boot ==

Durch die Installation werden die Links <code>vmlinuz</code> und <code>initrd</code> im Verzeichnis <code>/boot</code> angelegt. D.h der zuletzt installierte Kernel wird immer unter dem Namen <code>vmlinuz</code> zu finden sein.

Unser <code>/boot</code> Verzeichnis sollt nun so aussehen:

ls -al /boot
total 11246
drwxr-xr-x 4 root root 2048 Dec 10 07:03 .
drwxr-xr-x 22 root root 512 Dec 10 08:06 ..
-rw-r--r-- 1 root root 115852 Jul 28 20:57 Kerntypes-2.6.5-7.104-default
-rw-r--r-- 1 root root 741449 Jul 28 20:50 System.map-2.6.5-7.104-default
-rw-r--r-- 1 root root 740002 Dec 9 19:45 System.map-2.6.8-20041209164842-default
lrwxrwxrwx 1 root root 1 Jun 7 2004 boot -> .
-rw-r--r-- 1 root root 55554 Jul 28 20:57 config-2.6.5-7.104-default
-rw-r--r-- 1 root root 57559 Dec 9 20:01 config-2.6.8-20041209164842-default
drwxr-xr-x 2 root root 1024 Oct 14 08:23 grub
lrwxrwxrwx 1 root root 35 Dec 10 07:03 initrd -> initrd-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1383501 Aug 4 07:14 initrd-2.6.5-7.104-default
-rw-r--r-- 1 root root 1385622 Dec 10 07:03 initrd-2.6.8-20041209164842-default
drwx------ 2 root root 12288 Mar 11 2003 lost+found
-rw-r--r-- 1 root root 84480 Jul 20 19:46 message
-rw-r--r-- 1 root root 83147 Jul 2 2003 message.SuSEconfig.2003.07.09-14.54
-rw-r--r-- 1 root root 79374 Jul 28 20:58 symvers-2.6.5-7.104-i386-default.gz
-rw-r--r-- 1 root root 79146 Dec 9 20:03 symvers-2.6.8-20041209164842-i386-default.gz
-rw-r--r-- 1 root root 1738635 Jul 28 20:57 vmlinux-2.6.5-7.104-default.gz
-rw-r--r-- 1 root root 1856926 Dec 9 20:01 vmlinux-2.6.8-20041209164842-default.gz
lrwxrwxrwx 1 root root 36 Dec 10 07:00 vmlinuz -> vmlinuz-2.6.8-20041209164842-default
-rw-r--r-- 1 root root 1469887 Jul 28 20:50 vmlinuz-2.6.5-7.104-default
-rw-r--r-- 1 root root 1556730 Dec 9 19:45 vmlinuz-2.6.8-20041209164842-default

Wichtig ist, zu kontrollieren, dass <code>vmlinuz</code> auf den neuesten installierten Kernel zeigt. Gleiches gilt für <code>initrd</code>.

Der Eintrag für diesen Kernel (<code>vmlinuz</code>) ist in der Regel bereits in der <code>/boot/grub/menu.lst</code> enthalten.
Damit unser "alter" Kernel aber ebenfalls im GRUB-Menü ausgewählt werden kann, ist eine kleine Änderung an der <code>/boot/grub/menu.lst</code> erforderlich. Es muss ein zusätzlicher Eintrag für den alten Kernel erstellt werden.

Für unser Beispiel sollten die Einträge in der <code>/boot/grub/menu.lst</code> so aussehen:

title linux-kernel-of-the-day
kernel (hd0,0)/vmlinuz root=/dev/sda7 vga=788
initrd (hd0,0)/initrd

title linux-SuSE-default
kernel (hd0,0)/vmlinuz-2.6.5-7.104-default root=/dev/sda7 vga=788
initrd (hd0,0)/initrd-2.6.5-7.104-default

Nun kann man jederzeit einen neuen (experimentellen) Kernel installieren und hat den SuSE-default Kernel in der Hinterhand.
----
[[Kernel|zurück zum Kernel]]

[[Category:Kernel]]

Partition

2009-03-14T16:29:24Z

Josef-wien:

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]]
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle sichern und wiederherstellen]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

Partition

2009-03-14T16:28:53Z

Josef-wien: Ergänzung um Link zu: Partitionstabelle sichern und wiederherstellen

* [[Partitionierung und Verzeichnisstruktur ]]
* [[Zugriff auf Windows-Partitionen]]
* [[Mit dem /home auf neue Partition "umziehen"]]
* [[Reparieren einer defekten Partitionstabelle]]
* [[NonRaid zu (software)Raid1 SuSE 10 1]]
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[USB_Festplatte#Welches_Dateisystem.3F|Welches Dateisystem?]] - Die unterschiedlichen Dateisystem in der Computerwelt
* [[Partition eines Festplattenimage mounten| einzelne Partition eines kompletten Festplattenimage mounten]]
* [[Partitionstabelle_sichern_und_wiederherstellen]]

----

[[Hauptseite|zurück zur Hauptseite]]
[[Category:Partitionen]]

Diskussion:NonRaid zu (software)Raid1 SuSE 10 1

2008-10-05T15:37:29Z

Josef-wien: /* Erfahrung mit openSUSE 11.0 */

== Wie wollen wir mit diesem Thema in Zukunft umgehen ==

Dieses Howto wurde ursprünglich mal fürs Forum geschrieben. Die damals verwendetet Methode mit den Konsolausgaben zu arbeiten ist allerings hier im Wiki nicht sonderlich gut geeignet. Ursprünglich war es für 10.1 geschrieben (steht auch so noch im Namen), mittlerweile sind einige Befehlsoptionen enthalten, die es damals noch gar nicht gab. Auf 10.3 sind schon jetzt einige Dinge ganz anders, was sich in kommenden Versionen noch alles ändert ????
Wenn wir also hier weiterhin Änderungen vornehmen, dann kann es ganz schnell mal passieren, dass es unter irgend einer Version bei irgend jemanden mal schief geht. Wir laufen also Gefahr, das mit diesem Howto genau das passiert, was mit den meisten Howtos in diesem doch recht sensiblen und nicht einfachen Themenumfeld schon passiert ist, und eigentlich der Grund war, um es überhaupt nieder zu schreiben, " '''Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 ... funktionieren ''' "

=== Wie machen wir also weiter? ===
Möglichkeiten:
; Permanentlinks auf getestete Versionen :
im Kopf werden PermanentLinks auf getestete spezielle Versionen in der Historie gesetzt. Damit können Änderungen problemlos gemacht werden und immer auf der neuesten Version aktualisiert werden. Allerdings sind dann die "alten Versionen" nicht mehr korrigierbar und wir leben von der Zuverlässigkeit und Lebensdauer (500 glaube ich) der Historie

; alle Versionsunterschiede einarbeiten :
dann wird das hier schnell sehr unübersichtlich und uU überhaupt nicht mehr brauchbar

; für jede Version speziell überarbeitet selbstständige Beiträge :
hier müssten dann eventuell Änderungen doppelt und dreifach gemacht werden.

; komplett überarbeiten und ganz neu aufbauen :
hier stellt sich die Frage wer hat so viel Zeit und entsprechen die Möglichkeiten das alles an die verschiedenen Versionen zu testen.

[[Benutzer:Robi|Robi]] 19:26, 1. Feb. 2008 (CET)
=== Eure Meinung ist gefragt ===

-----

== Beispiel einer menu.lst bei openSUSE 10.3 ==

Als Hilfestellung hier noch einmal meine orginale und die entgültige menu.lst auf einem openSUSE 10.3.
Die Suspend to Disk Funktion wurde komplett abgeschalten, da sie zu Wechselwirkungen und Problemen mit dem gespiegeltem Swap führte.
Wer diese Funktion dennoch braucht, oder sonstige Hilfe oder spezielle Einstellungen für die einzelnen Kerneloptionen benötigt, sollte sich einmal im Verzeichnis
'''/usr/src/linux/Dokumentation''' umsehen. Dort sind einige Dateien wie zB. '''kernel-parameters.txt md.txt power/swsusp-and-swap-files.txt''' die hier sehr hilfreich sind.

Die Konfiguration wurde ausgetestet mit SCSI-Platten in Wechselrahmen (ohne irgend ein weiteres zusätzliches scsi-binding). Unter anderem hat folgendes problemlos funktioniert
* Entfernen eine Platte im laufendem Betrieb
* Zerstörung des MBR auf Platte /dev/sda und anschließendem reboot
* Entfernen der ersten Platte (also die Platte die normaler weise sda wird) und starten des Rechners
* hinzufügen und syncronisieren einer vorher entfernten Platte im laufenden Betrieb

'''Achtung:''' die beiden Ausdrucke der menu.lst enthalten Zeilenumbrüche die beim kopieren entstanden sind, sie wurden jedoch absichtlich nicht entfernt um hier im Wiki keine überlangen Zeilen zu produzieren.

=== Orginale menu.lst erstellt bei der Installation und/oder YaST ===
<pre>
# Modified by YaST2. Last modification on Wed Feb 20 03:26:32 CET 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 acpi=force resume=/dev/sda1 sp
lash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=normal showopts ide=nodma apm=off ac
pi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>

=== die für die Rootspiegelung geänderte menu.lst ===

<pre>
# Modified by ROBI. Last modification on Wed Feb 29 03:26:32 CET 2008
default 0
fallback 1
timeout 8
gfxmenu (hd0,1)/boot/message

#---------- RAID - A----------------#
title openSUSE 10.3 - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd0,1)/boot/initrd

#---------- RAID - B----------------#
title openSUSE 10.3 - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd1,1)/boot/initrd

#-------- failsafe--- A -----------#
title Failsafe - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd0,1)/boot/initrd

#-------- failsafe--- B -----------#
title Failsafe - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd1,1)/boot/initrd
</pre>

=== Verhalten dieser Konfiguration bei Kernelupdate ===

Jetzt gab es doch noch den lange ersehnten Kernelupdate, um diese obrige Konfiguration einmal bei einem Kernelupdate genau zu verfolgen. 
Der Update wurde mit Yast durchgeführt.

* Es gab während dieses Kernelupdates sowie vieler anderer Updates keinerlei Probleme
* erwartungsgemäß wurde eine für Raid sauber funktionierende '''initrd''' erstellt
* ein Grub-Update war nicht dabei, den hätte die Konfiguration wohl auch nicht schadlos überstanden. (Vielleicht, ehr jedoch unwahrscheinlich, kommt ja mal irgendwann ein solcher, dann werde ich das auch mal testen.)
* in der '''/boot/grub/menu.lst''' gab es von Yast folgende Änderungen.
<pre>
LINUX:/boot/grub # diff menu.lst.raid menu.lst
0a1
> # Modified by YaST2. Last modification on Mon Jun 23 20:48:29 CEST 2008
6a8,19
> ###Don't change this comment - YaST2 identifier: Original name: linux###
> title openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=0x317 acpi=force noresume splash=silent showopts
> initrd /boot/initrd-2.6.22.18-0.2-default
>
> ###Don't change this comment - YaST2 identifier: Original name: failsafe###
> title Failsafe -- openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
> initrd /boot/initrd-2.6.22.18-0.2-default
>
29a43,47
>
> ###Don't change this comment - YaST2 identifier: Original name: floppy###
> title Diskette
> rootnoverify (hd0,1)
> chainloader (fd0)+1
</pre>
* Yast hat also an den von mir gemachten Einträgen nichts geändert, sondern nur 3 Menü-Einträge neu dazu gesetzt. Die ersten beiden an den Anfang der Datei und die '''floppy''' ans Ende.
* mit Ausnahme des Kernel- und Initrd-Namens hat Yast dabei die Bootparameter aus der manuelle gemachten Konfiguration komplett übernommen.
* Alle so in der Datei '''menu.lst''' stehenden Einträge waren nach dem Update problemlos bootbar.
* Negativ ist aufgefallen, dass die '''menu.lst''' die vor dem Update aktiv war, hinterher komplett verschwunden war, und die '''menu.lst.old''' schon 2 der 3 von Yast getätigten Einträge beinhaltete. Es wurde also die '''menu.lst''' während des Updates 2 Mal verändert.

{{ Box Hinweis||Um also wieder in den Genuss der vollen urspünglichen Raidabsicherung des Bootprozesses zu gelangen, müssen die ersten beiden von Yast gemachten Einträge wieder entfernt werden, oder die '''default''' und '''fallback''' Optionen entsprechend geändert werden.}}

[[Benutzer:Robi|Robi]] 22:00, 23. Jun. 2008 (CEST)
-----

== Erfahrung mit openSUSE 11.0 ==

Herzlichen Dank für dieses wunderbare "HOWTO".

Falls es von Interesse ist: Unter openSUSE 11.0 funktioniert es wie beschrieben. Den Abschnitt "Anlegen einer identischen Partitionstabelle" habe ich nicht vollzogen, doch glaube ich nicht, daß unter 11.0 etwas anders wäre. "boot.md" habe ich wie beschrieben aktiviert. Irgendwelche aufgehenden KDE-Fenster gab es nicht. ".../disc/by-id/..." hat den Vorteil, eine Platte oder Partition zweifelsfrei zu identifizieren, aber "dev/sdb1" usw. funktioniert genauso. An eine Warnung von "mkinitrd" am Schluß des ersten Teils kann ich mich nicht erinnern. Zu den erwähnten Problemen hinsichtlich der Konbination von "gespiegeltem Swap" und "Suspend to disk" kann ich nichts sagen, da meine SWAP-Partition nicht gespiegelt wird. Zum Beenden der "grub-shell" habe ich auf Verdacht "quit" probiert, und das hat funktioniert. Zum Aktivieren der Systemmail reicht die im "HOWTO" beschriebene Vorgangsweise (beim normalen Benutzer muß im YaST natürlich "Systemmail empfangen" angekreuzt sein), die in einem anderen Artikel "Grub, Raid1 Ausfallsicherheit" angeführten zusätzlichen Postfix-Aktivitäten sind nicht erforderlich. Nachdem "/dev/md0" eine eindeutige Identifikation ist (im Gegensatz zu "/dev/sda1"), sehe ich hier keine Notwendigkeit zu einer ".../disc/by-id/..."-Angabe.

Ein Flüchtigkeitsfehler: Unter "Herstellung der Spiegelung" steht "cat mdstat" statt richtig "cat /proc/mdstat".

Ein Nachtrag: Sofern "powersave" installiert ist, kann alternativ oder zusätzlich zum e-mail auch eine POPUP-Nachricht erfolgen. In der Datei "mdadm.conf" ist eine Zeile
PROGRAM /Pfad/zum/Programm
einzutragen, das Programm ist ein "shell script" mit dem Inhalt: 
<nowiki>#! /bin/sh</nowiki> 
<nowiki>/usr/lib/powersave/powersave-notify "Your RAID1 drive is failing! </nowiki> 
<nowiki>mdadm message: $1 $2 $3"</nowiki>
Zwischen den Anführungszeichen kann beliebiger Text stehen, wichtig sind hier die Platzhalter $1, $2 und $3.

M.f.G. Josef

Diskussion:NonRaid zu (software)Raid1 SuSE 10 1

2008-10-05T15:27:01Z

Josef-wien: /* Erfahrung mit openSUSE 11.0 */

== Wie wollen wir mit diesem Thema in Zukunft umgehen ==

Dieses Howto wurde ursprünglich mal fürs Forum geschrieben. Die damals verwendetet Methode mit den Konsolausgaben zu arbeiten ist allerings hier im Wiki nicht sonderlich gut geeignet. Ursprünglich war es für 10.1 geschrieben (steht auch so noch im Namen), mittlerweile sind einige Befehlsoptionen enthalten, die es damals noch gar nicht gab. Auf 10.3 sind schon jetzt einige Dinge ganz anders, was sich in kommenden Versionen noch alles ändert ????
Wenn wir also hier weiterhin Änderungen vornehmen, dann kann es ganz schnell mal passieren, dass es unter irgend einer Version bei irgend jemanden mal schief geht. Wir laufen also Gefahr, das mit diesem Howto genau das passiert, was mit den meisten Howtos in diesem doch recht sensiblen und nicht einfachen Themenumfeld schon passiert ist, und eigentlich der Grund war, um es überhaupt nieder zu schreiben, " '''Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 ... funktionieren ''' "

=== Wie machen wir also weiter? ===
Möglichkeiten:
; Permanentlinks auf getestete Versionen :
im Kopf werden PermanentLinks auf getestete spezielle Versionen in der Historie gesetzt. Damit können Änderungen problemlos gemacht werden und immer auf der neuesten Version aktualisiert werden. Allerdings sind dann die "alten Versionen" nicht mehr korrigierbar und wir leben von der Zuverlässigkeit und Lebensdauer (500 glaube ich) der Historie

; alle Versionsunterschiede einarbeiten :
dann wird das hier schnell sehr unübersichtlich und uU überhaupt nicht mehr brauchbar

; für jede Version speziell überarbeitet selbstständige Beiträge :
hier müssten dann eventuell Änderungen doppelt und dreifach gemacht werden.

; komplett überarbeiten und ganz neu aufbauen :
hier stellt sich die Frage wer hat so viel Zeit und entsprechen die Möglichkeiten das alles an die verschiedenen Versionen zu testen.

[[Benutzer:Robi|Robi]] 19:26, 1. Feb. 2008 (CET)
=== Eure Meinung ist gefragt ===

-----

== Beispiel einer menu.lst bei openSUSE 10.3 ==

Als Hilfestellung hier noch einmal meine orginale und die entgültige menu.lst auf einem openSUSE 10.3.
Die Suspend to Disk Funktion wurde komplett abgeschalten, da sie zu Wechselwirkungen und Problemen mit dem gespiegeltem Swap führte.
Wer diese Funktion dennoch braucht, oder sonstige Hilfe oder spezielle Einstellungen für die einzelnen Kerneloptionen benötigt, sollte sich einmal im Verzeichnis
'''/usr/src/linux/Dokumentation''' umsehen. Dort sind einige Dateien wie zB. '''kernel-parameters.txt md.txt power/swsusp-and-swap-files.txt''' die hier sehr hilfreich sind.

Die Konfiguration wurde ausgetestet mit SCSI-Platten in Wechselrahmen (ohne irgend ein weiteres zusätzliches scsi-binding). Unter anderem hat folgendes problemlos funktioniert
* Entfernen eine Platte im laufendem Betrieb
* Zerstörung des MBR auf Platte /dev/sda und anschließendem reboot
* Entfernen der ersten Platte (also die Platte die normaler weise sda wird) und starten des Rechners
* hinzufügen und syncronisieren einer vorher entfernten Platte im laufenden Betrieb

'''Achtung:''' die beiden Ausdrucke der menu.lst enthalten Zeilenumbrüche die beim kopieren entstanden sind, sie wurden jedoch absichtlich nicht entfernt um hier im Wiki keine überlangen Zeilen zu produzieren.

=== Orginale menu.lst erstellt bei der Installation und/oder YaST ===
<pre>
# Modified by YaST2. Last modification on Wed Feb 20 03:26:32 CET 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 acpi=force resume=/dev/sda1 sp
lash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=normal showopts ide=nodma apm=off ac
pi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>

=== die für die Rootspiegelung geänderte menu.lst ===

<pre>
# Modified by ROBI. Last modification on Wed Feb 29 03:26:32 CET 2008
default 0
fallback 1
timeout 8
gfxmenu (hd0,1)/boot/message

#---------- RAID - A----------------#
title openSUSE 10.3 - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd0,1)/boot/initrd

#---------- RAID - B----------------#
title openSUSE 10.3 - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd1,1)/boot/initrd

#-------- failsafe--- A -----------#
title Failsafe - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd0,1)/boot/initrd

#-------- failsafe--- B -----------#
title Failsafe - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd1,1)/boot/initrd
</pre>

=== Verhalten dieser Konfiguration bei Kernelupdate ===

Jetzt gab es doch noch den lange ersehnten Kernelupdate, um diese obrige Konfiguration einmal bei einem Kernelupdate genau zu verfolgen. 
Der Update wurde mit Yast durchgeführt.

* Es gab während dieses Kernelupdates sowie vieler anderer Updates keinerlei Probleme
* erwartungsgemäß wurde eine für Raid sauber funktionierende '''initrd''' erstellt
* ein Grub-Update war nicht dabei, den hätte die Konfiguration wohl auch nicht schadlos überstanden. (Vielleicht, ehr jedoch unwahrscheinlich, kommt ja mal irgendwann ein solcher, dann werde ich das auch mal testen.)
* in der '''/boot/grub/menu.lst''' gab es von Yast folgende Änderungen.
<pre>
LINUX:/boot/grub # diff menu.lst.raid menu.lst
0a1
> # Modified by YaST2. Last modification on Mon Jun 23 20:48:29 CEST 2008
6a8,19
> ###Don't change this comment - YaST2 identifier: Original name: linux###
> title openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=0x317 acpi=force noresume splash=silent showopts
> initrd /boot/initrd-2.6.22.18-0.2-default
>
> ###Don't change this comment - YaST2 identifier: Original name: failsafe###
> title Failsafe -- openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
> initrd /boot/initrd-2.6.22.18-0.2-default
>
29a43,47
>
> ###Don't change this comment - YaST2 identifier: Original name: floppy###
> title Diskette
> rootnoverify (hd0,1)
> chainloader (fd0)+1
</pre>
* Yast hat also an den von mir gemachten Einträgen nichts geändert, sondern nur 3 Menü-Einträge neu dazu gesetzt. Die ersten beiden an den Anfang der Datei und die '''floppy''' ans Ende.
* mit Ausnahme des Kernel- und Initrd-Namens hat Yast dabei die Bootparameter aus der manuelle gemachten Konfiguration komplett übernommen.
* Alle so in der Datei '''menu.lst''' stehenden Einträge waren nach dem Update problemlos bootbar.
* Negativ ist aufgefallen, dass die '''menu.lst''' die vor dem Update aktiv war, hinterher komplett verschwunden war, und die '''menu.lst.old''' schon 2 der 3 von Yast getätigten Einträge beinhaltete. Es wurde also die '''menu.lst''' während des Updates 2 Mal verändert.

{{ Box Hinweis||Um also wieder in den Genuss der vollen urspünglichen Raidabsicherung des Bootprozesses zu gelangen, müssen die ersten beiden von Yast gemachten Einträge wieder entfernt werden, oder die '''default''' und '''fallback''' Optionen entsprechend geändert werden.}}

[[Benutzer:Robi|Robi]] 22:00, 23. Jun. 2008 (CEST)
-----

== Erfahrung mit openSUSE 11.0 ==

Herzlichen Dank für dieses wunderbare "HOWTO".

Falls es von Interesse ist: Unter openSUSE 11.0 funktioniert es wie beschrieben. Den Abschnitt "Anlegen einer identischen Partitionstabelle" habe ich nicht vollzogen, doch glaube ich nicht, daß unter 11.0 etwas anders wäre. "boot.md" habe ich wie beschrieben aktiviert. Irgendwelche aufgehenden KDE-Fenster gab es nicht. ".../disc/by-id/..." hat den Vorteil, eine Platte oder Partition zweifelsfrei zu identifizieren, aber "dev/sdb1" usw. funktioniert genauso. An eine Warnung von "mkinitrd" am Schluß des ersten Teils kann ich mich nicht erinnern. Zu den erwähnten Problemen hinsichtlich der Konbination von "gespiegeltem Swap" und "Suspend to disk" kann ich nichts sagen, da meine SWAP-Partition nicht gespiegelt wird. Zum Beenden der "grub-shell" habe ich auf Verdacht "quit" probiert, und das hat funktioniert. Zum Aktivieren der Systemmail reicht die im "HOWTO" beschriebene Vorgangsweise (beim normalen Benutzer muß im YaST natürlich "Systemmail empfangen" angekreuzt sein), die in einem anderen Artikel "Grub, Raid1 Ausfallsicherheit" angeführten zusätzlichen Postfix-Aktivitäten sind nicht erforderlich. Nachdem "/dev/md0" eine eindeutige Identifikation ist (im Gegensatz zu "/dev/sda1"), sehe ich hier keine Notwendigkeit zu einer ".../disc/by-id/..."-Angabe.

Ein Flüchtigkeitsfehler: Unter "Herstellung der Spiegelung" steht "cat mdstat" statt richtig "cat /proc/mdstat".

Ein Nachtrag: Sofern "powersave" installiert ist, kann alternativ oder zusätzlich zum e-mail auch eine POPUP-Nachricht erfolgen. In der Datei "mdadm.conf" ist eine Zeile
PROGRAM /Pfad/zum/Programm
einzutragen, das Programm ist ein "Shell script" mit dem Inhalt:
#! /bin/sh
/usr/lib/powersave/powersave-notify "Your RAID1 drive is failing! 
mdadm message: $1 $2 $3"

M.f.G. Josef

Diskussion:NonRaid zu (software)Raid1 SuSE 10 1

2008-09-29T15:59:04Z

Josef-wien: /* Erfahrung mit openSUSE 11.0 */

Diskussion:NonRaid zu (software)Raid1 SuSE 10 1

2008-09-24T15:35:09Z

Josef-wien: Neuer Abschnitt /* Erfahrung mit openSUSE 11.0 */

== Wie wollen wir mit diesem Thema in Zukunft umgehen ==

Dieses Howto wurde ursprünglich mal fürs Forum geschrieben. Die damals verwendetet Methode mit den Konsolausgaben zu arbeiten ist allerings hier im Wiki nicht sonderlich gut geeignet. Ursprünglich war es für 10.1 geschrieben (steht auch so noch im Namen), mittlerweile sind einige Befehlsoptionen enthalten, die es damals noch gar nicht gab. Auf 10.3 sind schon jetzt einige Dinge ganz anders, was sich in kommenden Versionen noch alles ändert ????
Wenn wir also hier weiterhin Änderungen vornehmen, dann kann es ganz schnell mal passieren, dass es unter irgend einer Version bei irgend jemanden mal schief geht. Wir laufen also Gefahr, das mit diesem Howto genau das passiert, was mit den meisten Howtos in diesem doch recht sensiblen und nicht einfachen Themenumfeld schon passiert ist, und eigentlich der Grund war, um es überhaupt nieder zu schreiben, " '''Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 ... funktionieren ''' "

=== Wie machen wir also weiter? ===
Möglichkeiten:
; Permanentlinks auf getestete Versionen :
im Kopf werden PermanentLinks auf getestete spezielle Versionen in der Historie gesetzt. Damit können Änderungen problemlos gemacht werden und immer auf der neuesten Version aktualisiert werden. Allerdings sind dann die "alten Versionen" nicht mehr korrigierbar und wir leben von der Zuverlässigkeit und Lebensdauer (500 glaube ich) der Historie

; alle Versionsunterschiede einarbeiten :
dann wird das hier schnell sehr unübersichtlich und uU überhaupt nicht mehr brauchbar

; für jede Version speziell überarbeitet selbstständige Beiträge :
hier müssten dann eventuell Änderungen doppelt und dreifach gemacht werden.

; komplett überarbeiten und ganz neu aufbauen :
hier stellt sich die Frage wer hat so viel Zeit und entsprechen die Möglichkeiten das alles an die verschiedenen Versionen zu testen.

[[Benutzer:Robi|Robi]] 19:26, 1. Feb. 2008 (CET)
=== Eure Meinung ist gefragt ===

-----

== Beispiel einer menu.lst bei openSUSE 10.3 ==

Als Hilfestellung hier noch einmal meine orginale und die entgültige menu.lst auf einem openSUSE 10.3.
Die Suspend to Disk Funktion wurde komplett abgeschalten, da sie zu Wechselwirkungen und Problemen mit dem gespiegeltem Swap führte.
Wer diese Funktion dennoch braucht, oder sonstige Hilfe oder spezielle Einstellungen für die einzelnen Kerneloptionen benötigt, sollte sich einmal im Verzeichnis
'''/usr/src/linux/Dokumentation''' umsehen. Dort sind einige Dateien wie zB. '''kernel-parameters.txt md.txt power/swsusp-and-swap-files.txt''' die hier sehr hilfreich sind.

Die Konfiguration wurde ausgetestet mit SCSI-Platten in Wechselrahmen (ohne irgend ein weiteres zusätzliches scsi-binding). Unter anderem hat folgendes problemlos funktioniert
* Entfernen eine Platte im laufendem Betrieb
* Zerstörung des MBR auf Platte /dev/sda und anschließendem reboot
* Entfernen der ersten Platte (also die Platte die normaler weise sda wird) und starten des Rechners
* hinzufügen und syncronisieren einer vorher entfernten Platte im laufenden Betrieb

'''Achtung:''' die beiden Ausdrucke der menu.lst enthalten Zeilenumbrüche die beim kopieren entstanden sind, sie wurden jedoch absichtlich nicht entfernt um hier im Wiki keine überlangen Zeilen zu produzieren.

=== Orginale menu.lst erstellt bei der Installation und/oder YaST ===
<pre>
# Modified by YaST2. Last modification on Wed Feb 20 03:26:32 CET 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 acpi=force resume=/dev/sda1 sp
lash=silent showopts
initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.17-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGAT
E_ST336704LC_3CD27AAG00002206F766-part2 vga=normal showopts ide=nodma apm=off ac
pi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd /boot/initrd-2.6.22.17-0.1-default
</pre>

=== die für die Rootspiegelung geänderte menu.lst ===

<pre>
# Modified by ROBI. Last modification on Wed Feb 29 03:26:32 CET 2008
default 0
fallback 1
timeout 8
gfxmenu (hd0,1)/boot/message

#---------- RAID - A----------------#
title openSUSE 10.3 - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd0,1)/boot/initrd

#---------- RAID - B----------------#
title openSUSE 10.3 - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=0x317 acpi=force noresume spla
sh=silent showopts
initrd (hd1,1)/boot/initrd

#-------- failsafe--- A -----------#
title Failsafe - sda
root (hd0,1)
kernel (hd0,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd0,1)/boot/initrd

#-------- failsafe--- B -----------#
title Failsafe - sdb
root (hd1,1)
kernel (hd1,1)/boot/vmlinuz root=/dev/md0 vga=normal showopts ide=nodma apm=
off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
initrd (hd1,1)/boot/initrd
</pre>

=== Verhalten dieser Konfiguration bei Kernelupdate ===

Jetzt gab es doch noch den lange ersehnten Kernelupdate, um diese obrige Konfiguration einmal bei einem Kernelupdate genau zu verfolgen. 
Der Update wurde mit Yast durchgeführt.

* Es gab während dieses Kernelupdates sowie vieler anderer Updates keinerlei Probleme
* erwartungsgemäß wurde eine für Raid sauber funktionierende '''initrd''' erstellt
* ein Grub-Update war nicht dabei, den hätte die Konfiguration wohl auch nicht schadlos überstanden. (Vielleicht, ehr jedoch unwahrscheinlich, kommt ja mal irgendwann ein solcher, dann werde ich das auch mal testen.)
* in der '''/boot/grub/menu.lst''' gab es von Yast folgende Änderungen.
<pre>
LINUX:/boot/grub # diff menu.lst.raid menu.lst
0a1
> # Modified by YaST2. Last modification on Mon Jun 23 20:48:29 CEST 2008
6a8,19
> ###Don't change this comment - YaST2 identifier: Original name: linux###
> title openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=0x317 acpi=force noresume splash=silent showopts
> initrd /boot/initrd-2.6.22.18-0.2-default
>
> ###Don't change this comment - YaST2 identifier: Original name: failsafe###
> title Failsafe -- openSUSE 10.3 - 2.6.22.18-0.2
> root (hd0,1)
> kernel /boot/vmlinuz-2.6.22.18-0.2-default root=/dev/md0 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
> initrd /boot/initrd-2.6.22.18-0.2-default
>
29a43,47
>
> ###Don't change this comment - YaST2 identifier: Original name: floppy###
> title Diskette
> rootnoverify (hd0,1)
> chainloader (fd0)+1
</pre>
* Yast hat also an den von mir gemachten Einträgen nichts geändert, sondern nur 3 Menü-Einträge neu dazu gesetzt. Die ersten beiden an den Anfang der Datei und die '''floppy''' ans Ende.
* mit Ausnahme des Kernel- und Initrd-Namens hat Yast dabei die Bootparameter aus der manuelle gemachten Konfiguration komplett übernommen.
* Alle so in der Datei '''menu.lst''' stehenden Einträge waren nach dem Update problemlos bootbar.
* Negativ ist aufgefallen, dass die '''menu.lst''' die vor dem Update aktiv war, hinterher komplett verschwunden war, und die '''menu.lst.old''' schon 2 der 3 von Yast getätigten Einträge beinhaltete. Es wurde also die '''menu.lst''' während des Updates 2 Mal verändert.

{{ Box Hinweis||Um also wieder in den Genuss der vollen urspünglichen Raidabsicherung des Bootprozesses zu gelangen, müssen die ersten beiden von Yast gemachten Einträge wieder entfernt werden, oder die '''default''' und '''fallback''' Optionen entsprechend geändert werden.}}

[[Benutzer:Robi|Robi]] 22:00, 23. Jun. 2008 (CEST)
-----

== Erfahrung mit openSUSE 11.0 ==

Herzlichen Dank für dieses wunderbare "HOWTO".

Falls es von Interesse ist: Unter openSUSE 11.0 funktioniert es wie beschrieben. Den Abschnitt "Anlegen einer identischen Partitionstabelle" habe ich nicht vollzogen, doch glaube ich nicht, daß unter 11.0 etwas anders wäre. "boot.md" habe ich wie beschrieben aktiviert. Irgendwelche aufgehenden KDE-Fenster gab es nicht. ".../disc/by-id/..." hat den Vorteil, eine Platte oder Partition zweifelsfrei zu identifizieren, aber "dev/sdb1" usw. funktioniert genauso. An eine Warnung von "mkinitrd" am Schluß des ersten Teils kann ich mich nicht erinnern. Zu den erwähnten Problemen hinsichtlich der Konbination von "gespiegeltem Swap" und "Suspend to disk" kann ich nichts sagen, da meine SWAP-Partition nicht gespiegelt wird. Zum Beenden der "grub-shell" habe ich auf Verdacht "quit" probiert, und das hat funktioniert. Zum Aktivieren der Systemmail reicht die im "HOWTO" beschriebene Vorgangsweise (beim normalen Benutzer muß im YaST natürlich "Systemmail empfangen" angekreuzt sein), die im "Link auf die Diskussionseite" angeführten zusätzlichen Postfix-Aktivitäten sind nicht erforderlich. Nachdem "/dev/md0" eine eindeutige Identifikation ist (im Gegensatz zu "/dev/sda1"), sehe ich hier keine Notwendigkeit zu einer ".../disc/by-id/..."-Angabe.

Ein Flüchtigkeitsfehler: Unter "Herstellung der Spiegelung" steht "cat mdstat" statt richtig "cat /proc/mdstat".

M.f.G. Josef