eisfair-Installation von IDE- auf SATA-HD oder 3Ware-RAID clonen
- Yves Schumann (Unlicensed)
Vorausetzungen:
Benötigt wird folgende Hardware:
- Rechner mit CD-ROM Laufwerk
- eine IDE-Festplatte auf der das Eisfair System mit dem Kernel 2.4.35-wt1 (SMP oder single-Core Variante) instaliert ist
- eine Knoppix CD (habe die vom anfang 2007 verwendet)
- eine SATA-Festplatte oder ein im Bios des 3ware Controllers erstelltes Raid-Array
Vorbereitung der SATA-Festplatte bzw. des Raid-Verbundes:
Eisfair herunterfahren, die SATA-Festplatte oder den 3ware Controller einbauen (und auch die Festplatten die im RAID fungieren sollen). Eisfair starten und von der IDE Festplatte booten (für diejenigen die Ihr eisfair-System von einem 3ware Controller booten wollen, gibt es jetzt die Möglichkeit mit <ALT+3> ins Bios des Controllers zu gehen und das RAID-Array zu erstellen). Ist der Bootvorgang beendet, meldet man sich als root an und lädt die notwendige Module um seine SATA-Festplatte bzw. den RAID Controller mounten zu können.
Dazu gibt man je nach Mainbaord folgendes ein :
modprobe scsi_mod modprobe sd_mod modprobe libata modprobe ata_piix
modprobe scsi_mod modprobe sd_mod modprobe libata modprobe sata_nv
Die Module, die für den SATA-Controller benötigt werden, findet man namentlich im Ordner /lib/modules/2.4.35-wt1(-SMP)/kernel/drivers/scsi. Sie beginnen alle bis auf das Intel Modul (ata_piix) mit sata_ .
Bei dem 3ware RAID Controller genügt es folgende Module zu laden:
modprobe scsi_mod modprobe sd_mod modprobe libata modprobe 3w-9xxx # oder modprobe 3w-xxxx
Einschub bezüglich der Datei modules.dep und Abhängigkeiten der Module
Die Abhängigkeiten der Module, findet man in der Datei modules.dep, die sich im Ordner /lib/modules/2.4.35-wt1(-SMP) befindet. Diese Datei gibt dem Kernel Auskunft darüber, welche Treiber bzw. Module ihm zur Verfügung stehen und in welcher Abhängigkeit sie zueinander stehen. Abhängigkeit heißt hierbei, dass bestimmte Module geladen sein müssen bevor ich mein eigentlich gewünschtes Modul laden kann. Ich denke man kann es am besten an einem Beispiel erklären, ich nehme mir die Freiheit es an dem o.g. Modul für die Unterstützung der SATA Geräten an einem Intel System zu erklären. Wie oben beschrieben, benötigt man das ata_piix.o Modul um z.B. eine Festplatte am SATA Port eines Intel Systems anzusprechen, aber warum müssen die anderen Module (scsi_mod sd_mod libata ata_piix) geladen sein, bevor man das eigentliche ata_piix Modul laden kann? Hierzu schauen wir uns die modules.dep Datei genauer an, bzw. wir durchsuchen sie nach dem Namen ata_piix.o und finden u.a. folgende Zeile und deuten sie wie folgt:
/lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/ata_piix.o: /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/libata.o \ /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/scsi_mod.o
- Das \ Zeichen bedeutet, dass hier ein Zeilenumbruch stattfindet und das die nachfolgende "Zeile" eigentlich zu der Vorherigen gehört
- Die Module libata.o und scsi_mod.o müssen vor dem ata_piix.o Modul geladen sein (das ist die o.g. Abhängigkeit)
Da wir noch nicht wissen, ob eine Abhängigkeit zwischen den Modulen (libata.o und scsi_mod.o) besteht, würde der Zwischenstand bei der Reihenfolge, beim Laden der Module wie folgt ausehen :
- libata.o
- scsi_mod.o
- ata_piix.o
oder
- scsi_mod.o
- libata.o
- ata_piix.o
Des Weiteren müssen wir uns vergewissern, ob die beiden Module von weiteren abhängig sind. Jetzt duchsuchen wir die Datei modules.dep nach libata.o, wobei das Modul an der ersten Stelle der Zeile auftauchen sollte. Das Ergebniss sieht so aus:
/lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/libata.o: /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/scsi_mod.o
Das heißt scsi_mod.o muss geladen sein bevor wir libata.o laden können. Die neue Reihenfolge der zu ladenen Module würde so aussehen:
- scsi_mod.o
- libata.o
- ata_piix.o
Zu untersuchen bleibt noch von welchen Modulen das Modul scsi_mod.o abhängig ist. Hierzu suchen wir wieder in der Datei modules.dep, diesmal nach dem Modul scsi_mod.o und finden keine Einträge. Für SATA-Festplatten brauchen wir noch das Modul sd_mod.o. Warum? Wir haben bis jetzt die SATA Schnittstelle des Mainboards in Gang gesetzt. Die Geräte, die wir an dieser Schnittstelle betreiben wollen, benötigen aber auch einen Treiber. Für Geräte vom Typ 0,7,14 (wobei eine magnetische Festplatte mit Typ 0 auch darunter fällt) benötigen wir das sd_mod.o Modul. (sieheen.wikipedia.org/wiki/SCSI_Peripheral_Device_Type )
Bei der Suche nach der Abhängigkeit des Moduls sd_mod.o stoßen wir in der Datei modules.dep auf folgende Zeile:
/lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sd_mod.o: /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/scsi_mod.o
Hieraus ergibt sich die neue und entgültige Reihenfolge und Menge der zu ladenden Module und die sieht, wie auch o.g., wie folgt aus:
- scsi_mod.o
- sd_mod
- libata.o
- ata_piix.o
Man kann natürlich auch andere Module in der initrd unterbringen, die man vor dem ersten Zugriff auf die Festplatte benötigt wie z.B. das xfs.o Modul, das für den Zugriff aufs X File System von der Fa. SGI benötigt wird, sofern man die root-Partition seines eisfair-Systems auf einer solchen Partition installiert hat. Dabei aber immer die Abhängigkeit der Module in der modules.dep "nachforschen"
Weiter im Kontext
Spätestens jetzt sollte die SATA Festplatte oder der RAID-Controller ansprechbar sein. Testen kann man es indem man folgendes eingibt:
fdisk -l
Die Ausgabe sollte in etwa so ausehen:
Disk /dev/hda: 255 heads, 63 sectors, 391 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 17 136521 83 Linux /dev/hda2 18 83 530145 82 Linux swap /dev/hda3 84 391 2474010 83 Linux Disk /dev/sda: 255 heads, 63 sectors, 90786 cylinders Units = cylinders of 16065 * 512 bytes
Hier sieht man, das fdisk die Festplatte/Raidverbund ansprechen kann.
PS.: eisfair benennt die IDE-Festplatten mit hdxy, wobei x entweder für a (primäry master), b (primary slave), c (secondery master ), d (secondery slave) steht, y hingegen gibt die Partitionsnummer an. Bei SCSI oder SATA Festplatten fangen die laufwerke mit s an also sda, sdb usw. Sollte an der Stelle mit >fdisk -l< die SATA-Festplatte nichtangezeigt werden, kann man die SATA Module durchprobieren. Dabei gilt als Daumenregel, dass die Module
- scsi_mod
- sd_mod
- libata
Pflicht sind und das Modul ata_piix für das Modul steht, was man im System hat. Läd man z.B. das ata_piix Modul auf einem Nvidia Mainboard dann sieht die Ausgabe so aus:
Server # modprobe sata_nv /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sata_nv.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sata_nv.o: insmod /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sata_nv.o failed /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sata_nv.o: insmod sata_nv failed Server #
Hier sieht man, das entweder
- Die Hardware zu neu für das Modul ist (hier vielleicht lieb bei Thomas Bork anklopfen und bitten, das er das Modul aktualisiert) oder
- Die Hardware, welche das Modul unterstützt nicht verbaut ist.
Hat man ein Modul erfolgreich geladen, dann sieht man keinerlei Fehlermeldungen und das Modul erscheint auch bei der Eingabe von:
lsmod
in der Tabelle. Hat man ein Modul erfolgreich geladen, dann sofort danach
fdisk -l
ausführen um zu gucken ob die SATA-Festplatte bzw. der RAID-Controller sichtbar bzw. ansprechbar ist. Hat man alle SATA Module duchprobiert und die Festplatte ist immernoch nicht in Sicht, dann kann man jetzt aufhören und muss wohl oder übel zum nächsten eisfair Kernel-Update warten. Für diejenigen, die Ihre Festplatte "sehen können" geht es mit folgendem Kapitel weiter...
Formatieren der SATA Festplatte/Raid Verbundes
Nehmen wir an
fdisk -l
zeigt uns die SATA Festplatte als
/dev/sda
an, dann machen wir uns ans Werk und erstellen das "Fundament" für Unser neues SATA eisfair System indem wir die Partitionen auf der neuen Festplatte/Raidverbund erstellen und anschließend formatieren:
fdisk /dev/sda
(jetzt sind wir im Menu des fdisk, um eine z.B. 64 MB große Boot partition zu erstellen geben wir nacheinander folgendes ein, wobei >Return< für die Return-taste steht und nicht dass man es eingeben sollte, ich gehe hier davon aus dass die neue Festplatte blitzeblank ist d.h. keine partitionen auf Ihr angelegt wurden und zum jetzigen Zeitpunkt immernoch drauf exsistieren)
- n >Return<
- p >Return<
- 1 >Return<
- >Return<
- +64M >Return<
- t >Return<
- 1 >Return<
- 83 >Return<
- a >Return<
- 1 >Return<
(So, jetzt ist die bootpartition erstellt und auch bootfähig gemacht worden, als nähstes die Swap Partition erstellen. Man sagt dass sie doppelt so groß sein sollte wie der RAM aber das hängt von der Nutzung des Eisfair Systems ab, bei der Nutzung als File oder Webservers oder P2P Servers, dass alles gleichzeitig wird bei 2 GB Ram der swap fast garnicht genutzt, man bedenke dass man für ein DDR2-RAM 2 GB Kit gerademal 30 Euro bezahlt, ich gehe hier mal von 512 MB Swap aus, also weiter die eingabe im fdisk Menü:)
- n >Return<
- p >Return<
- 2 >Return<
- >Return<
- +512M >Return<
- t >Return<
- 2 >Return<
- 82 >Return<
(Swap ist erstellt jetzt noch eine letzte Partition für das root system, ich gehe davon aus dass die gesamte Festplatte dem Eisfair System zum Opfer fallen sollte :-) also gehen wir weiter im fdisk menü so vor:)
- n >Return<
- p >Return<
- 3 >Return<
- >Return<
- >Return<
- t >Return<
- 3 >Return<
- 83 >Return<
(sollte nur ein Teil der Festplatte fürs root System genutzt werden trägt man die gewünschte Größe in MB anstatt von xxx ein, es würde dann so ausehen:)
- n >Return<
- p >Return<
- 3 >Return<
- >Return<
- +xxxM >Return<
- t >Return<
- 3 >Return<
- 83 >Return<
So weit so gut, mit Eingabe von:
p >Return<
sollte man dann Quantitativ folgende Ausgabe bekommen:
Command (m for help): p Disk /dev/sda: 255 heads, 63 sectors, 391 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 17 136521 83 Linux /dev/sda2 18 83 530145 82 Linux swap /dev/sda3 84 391 2474010 83 Linux Command (m for help):
als nähstes (sofern man mit der Partitionierung zufrieden ist Speichert man die Konfiguration und verläßt anschließend das >fdisk< tool indem man:
w >Return<
eingibt. Jetzt sollte man die Partitionen formatieren, ich habe mich für das ext3 Format für die boot und root partition entschieden und swap bleibt ja swap. Also wie folgt vorgehen :
mkfs.ext3 /dev/sda1 mkfs.ext3 /dev/sda3 mkswap -c /dev/sda2 fsck /dev/sda1 fsck /dev/sda3
so, jetzt ist die festplatte "startfertig" für den nähsten Schritt das Klonen, zuvor sollte das System mit >halt< heruntergefahren werden ...
Spiegeln eines bestehenden Eisfair Systems
Wie zuvor erwähnt brauchen wir jetzt eine knoppix CD und ein CD-Rom Laufwerk. Man bootet von der Knoppix CD und am anfang gibt man als bootparameter
knoppix 2 dma
ein, das System fährt in den Runlevel 2 und aktiviert den DMA Support (beide Festplatten sollten angeschlossen sein (IDE und SATA)). Jetzt kann das "Klonen" anfangen, hier geht man so vor:
cd / mkdir /x mkdir /x/hda mkdir /x/sda mount /dev/hda1 /x/hda mount /dev/sda1 /x/sda cp -a /x/hda/* /x/sda/ umount /x/hda umount /x/sda mount /dev/hda3 /x/hda mount /dev/sda3 /x/sda cp -a /x/hda/* /x/sda/ umount /x/hda umount /x/sda reboot
jetzt ist die Festplatte "Geklont".
Erstellen einer angepassten Initial-Ram-Disk
Sinn der Kapitels ist dieser dass der Kernel keine Module von einer Festplatte laden kann die er noch nicht kennt bzw. die noch nicht kennengelernt hat indem er von Ihr das benötigte Modul geladen hat um auf sie zuzugreifen, das ist nicht kausal. Es ist vieleicht mit dem Einschlag einer Gewehrkugel auf ein Objekt vergleichbar wobei die Kugel noch nicht abgefeuert wurde, es muss eine Reihenfolge eingehalten werden erstmal Gewehr abfeuern dann zischt die Kugel los und dann knallt die irgendwo rein umgekehrt ist es nicht möglich, genau wie bei dem laden eines Treibers von einem Gerät für das man noch keinen Treiber geladen hat.
Wie am Ende des zuvorgehenden Kapitels von der IDE Festplatte gebootet melden wir uns als root an, packen die die initrd.gz aus, mounten sie, fügen die fehlenden Module ein und "zwingen" den kernel diese auch zu booten, dazu gehen wir wie folgt vor:
mkdir /x cp -a /boot/initrd.gz /x/ mkdir /x/x cd /x gzip -d initrd.gz modprobe loop mount -o loop initrd /x/x
Jetzt müssen die fehlenden Module die wir gebraucht haben um unsere Festplatte/Controler zu mounten vom
/lib/modules/2.4.35-wt1(-SMP)/kernel/drivers/scsi/
nach
/x/x/lib/modules/2.4.35-wt1(-SMP)/
kopiert werden (der SMP zusatz steht für ein SMP Kernel System bei singlecore Systemen wird er warscheinlich nicht vorhanden sein). Am besten funktioniert es mit >MidnightCommander<. Hier sollte man genau im Gedächniss haben welche es waren, zur Erinnerung bei einem Mainboard mit Intel Chipsatz sind es die folgenden:
scsi_mod.o sd_mod.o libata.o ata_piix.o
hat man nun die module in die gemountete initrd kopiert verläßt man den MidnightCommander und läd die kopierten Module nochmals mit modprobe, hier kann man sehen ob es auch alle waren und die Reihenfolge stimmt
damit die SATA Festplatte/Raidverbund ansprechbar sind, hier zur Erinnerung als Beispiel für Mainboard's mit Intel Chipsatz:
modprobe scsi_mod modprobe sd_mod modprobe libata modprobe ata_piix
jetzt noch nachschauen ob die SATA Festplatten anschprechbar sind mit Eingabe von:
fdisk -l
sollte jetzt auch sda zu sehen sein:
Server # fdisk -l Disk /dev/sda: 255 heads, 63 sectors, 391 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 17 136521 83 Linux /dev/sda2 18 83 530145 82 Linux swap /dev/sda3 84 391 2474010 83 Linux
da wir uns die module und die Reihenfolge gemerkt haben müssen wir den kernel "zwingen" diese auch beim booten zu laden. das erreichen wir indem wir, hier weiter am Beispiel des Intel Systems, die folgende Datei wie folgt modifizieren:
joe /x/x/linuxrc
Vorher :
#! /bin/sh echo -e "\033[32m\033[49mloading SCSI drivers ...\033[0m" /sbin/insmod.static input /sbin/insmod.static keybdev /sbin/insmod.static mousedev /sbin/insmod.static usbcore /sbin/insmod.static hid
Nachher :
#! /bin/sh echo -e "\033[32m\033[49mloading SCSI drivers ...\033[0m" /sbin/insmod.static input /sbin/insmod.static keybdev /sbin/insmod.static mousedev /sbin/insmod.static usbcore /sbin/insmod.static hid /sbin/insmod.static scsi_mod /sbin/insmod.static sd_mod /sbin/insmod.static libata /sbin/insmod.static ata_piix /sbin/insmod.static 3w-9xxx # nur bei 3ware Raid System oder /sbin/insmod.static 3w-xxxx # nur bei 3ware Raid System
anschließend die Datei mit
STRG+k x
abspeichern und schließen. Jetzt können wir die initrd unmounten und sie wieder zusammenpacken:
cd /x umount /x/x gzip -9 initrd
jetzt sollte die SATA Festplatte/Raidcontroler immernoch ansprechbar sein also gehen wir zum nähsten Schritt über und machen die SATA Festplatte/Controler bootbar.
Festplatte "bootbar" machen
Die nun erstellte initrd.gz die sich /x befindet werden wir nun benutzen um von der neuen Festplatte booten zu können, dazu gehen wir wie folgt vor:
umount /boot mount /dev/sda1 /boot cp -a /x/initrd.gz /boot/ cp -a /etc/lilo.conf /etc/lilo.conf.org joe /etc/lilo.conf
lba32 disk = /dev/hda bios = 0x80 boot = /dev/hda read-only prompt timeout = 50 vga = normal image = /boot/kernel root = /dev/hda3 label = eis initrd = /boot/initrd.gz image = /boot/old-kernel root = /dev/hda3 label = oldeis initrd = /boot/old-initrd.gz
lba32 disk = /dev/sda bios = 0x80 boot = /dev/sda read-only prompt timeout = 50 vga = normal image = /boot/kernel root = /dev/sda3 label = eis initrd = /boot/initrd.gz image = /boot/old-kernel root = /dev/sda3 label = oldeis initrd = /boot/old-initrd.gz
jetzt das ganze speichern und den joe editor beenden:
STRG+k x
jetzt müssen wir noch lilo beibringen auch von der SATA festplatte/Raid zu booten und Lilo auch in den MBR der neuen Festplatte instalieren (funktioniert beim Raidverbund genauso) dazu folgendes eingeben:
lilo -A /dev/sda 1 lilo -M /dev/sda mbr lilo cp -a /etc/lilo.conf.org /etc/lilo.conf rm /etc/lilo.conf.org
bevor wir den neustart des Systems einleuten müssen wir noch den fstab auf der SATA Festplatte/Raidverbund anpassen, dazu gehen wir wie folgt vor:
mount /dev/sda3 /x/x joe /x/x/etc/fstab
/dev/hda3 / ext3 defaults,errors=remount-ro 0 1 /dev/hda1 /boot ext3 defaults,errors=remount-ro 0 1 /dev/hda2 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy auto defaults,user,noauto 0 0 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0 devpts /dev/pts devpts defaults 0 0
/dev/sda3 / ext3 defaults,errors=remount-ro 0 1 /dev/sda1 /boot ext3 defaults,errors=remount-ro 0 1 /dev/sda2 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy auto defaults,user,noauto 0 0 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0 devpts /dev/pts devpts defaults 0 0
jetzt das ganze speichern und den joe editor beenden:
STRG+k x umount /x/x halt
Jetzt kann man das CD-Rom Laufwerk und die IDE festplatte abklemmen, man sollte aber wie zuvor erwähnt die SATA festplatte bzw. das Raidverbund als erste quelle beim bootvorgang des Mainboards einstellen. Das System sollte jetzt in der Lage sein von SATA/Raid zu booten und man hat sein altes System auf neuem Medium. Die Zukünftigen kernel Updates seitens des Eisfair-Teams sollten ebenfalls kein Problem darstellen.
PS.: Sollte das System aus welchem Grund immer noch nicht booten können so hat man zur Sicherheit seine alte IDE Festplatte die im Prinzip von der Veränderung nichts mitbekommen hat, die kann man immernoch anschließen und im Bios des Mainboard die IDE Festplatte als erstes Bootmedium einstellen, man macht nichts dadurch "Kaputt"
So nun aber viel Glück mit dem neuen System.
MfG
Christof Grobelny