Problem:
Der Kernel der Installations-CD ist zu alt und erkennt die neuere Hardware (RAID-Controller, Chipsatz, etc.) des neuen Servers nicht. Installation endet in einer Endlosschleife der Hardwareerkennung...
In dem hier beschriebenen Fall handelt es sich um die 2.2 RC3 Version mit integriertem Kernel 2.6.22.19-72.Endian15.
Ziel-Hardware:
-
Mainboard: Supermicro SMCI-X7DCLi, Chipsatz Intel 5100, 2x LAN 1GBit Intel 82573V/L
-
Prozessor: Intel Xeon E5405
-
Arbeitsspeicher: 2 GB ECC
-
RAID-Controller: 3Ware Escalade 9650SE-2LP, PCI-e, RAID1 mit 2x160GB
Lösung:
Klappt das Booten mit einer Live-CD einer anderen Linux-Distribution, die einen neueren Kernel verwendet, und kann diese die Hardware auch erkennen und ansprechen, kann man eine bestehende EFW mit dem neuen Kernel nachrüsten.
Vorraussetzung: EFW muss bereits auf einem anderen Rechner installiert sein.
Ablauf:
1. Fremdkernel installieren, hier: Debian-basierter Kernel:
debian-Installation (hier: Debian 5.0, Kernel 2.6.26 i386/686), expert-installation
- Partitionierung (Beispiel 160 GB), 4 Partitionen:Code
1: /boot, 100 MB 2: swap, 4 GB 3: /, 55,9 GB 4: /var, 100 GB - Grundsystem installieren
- Kernel installieren (einen auswählen, hier 2.6.26-2-686) (alle Treiber)
- Grub in den MBR installieren lassen (nicht Grub V2 (experimental))
2. Kernel sichern und Platte neu formatieren:
- Knoppix starten (Bootparameter knoppix 2)
Kerneldaten auf einen Stick oder anderes Medium kopieren (hier: /tmp)Codemount /media/sda1 mount /media/sda3 rsync -av /media/sda1/* /tmp/boot rmdir /tmp/boot/lost+found/ rsync -av /media/sda3/lib/modules/* /tmp/modules/media/sda1 (Bootpartition), /media/sda3 (Systempartition)
- Partitionen neu formatierenCode
umount /media/sda1 umount /media/sda3 mkfs.ext3 -m 1 /dev/sda1 mkfs.ext3 -m 0.3 /dev/sda3 mkfs.ext3 -m 0.2 /dev/sda4Parameter m = Prozentualer Anteil der reservierten Blöcke für Superuser
3. Endian Firewall kopieren:
rsync -avz -e ssh remoteuser@remotehost:/remote/dir /this/dir/remoteuser=root, remotehost=Servername der Quelle, /remote/dir=die jeweiligen Verzeichnisse, /this/dir=die Zielpartition
mount /media/sda1
mount /media/sda3
mount /media/sda4
rsync -av -e ssh root@remotehost:/boot/* /media/sda1
for I in bin etc home lib mnt opt root sbin tmp usr; do rsync -avz -e ssh root@remotehost:/$I /media/sda3; done
rsync -av -e ssh root@remotehost:/var/* /media/sda44. Links erstellen und neue Kernel-Dateien kopieren:
- mount-Verzeichnisse und System-Verzeichnisse:Code
mkdir /media/sda3/boot /media/sda3/var /media/sda3/dev /media/sda3/proc /media/sda3/sys cp /tmp/boot/*-2.6.26-2-686 /media/sda1 - für alte Dateien in /media/sda1 Sicherungen erstellen und anschließend neue verlinken:
- a) als bash-Schleife:Code
cd /media/sda1 ls -1 *2.6.22* | while read I; do mv $I $I.old; NEU=`ls -1 ${I:0:5}*-2.6.26*`; ln -s $NEU $I; done - b) als Einzel-Befehle:Code
cd /media/sda1 mv config-2.6.22.19-72.endian15 config-2.6.22.19-72.endian15.old mv initrd-2.6.22.19-72.endian15.img initrd-2.6.22.19-72.endian15.img.old mv System.map-2.6.22.19-72.endian15 System.map-2.6.22.19-72.endian15.old mv vmlinuz-2.6.22.19-72.endian15 vmlinuz-2.6.22.19-72.endian15.old ln -s config-2.6.26-2-686 config-2.6.22.19-72.endian15 ln -s initrd.img-2.6.26-2-686 initrd-2.6.22.19-72.endian15.img ln -s System.map-2.6.26-2-686 System.map-2.6.22.19-72.endian15 ln -s vmlinuz-2.6.26-2-686 vmlinuz-2.6.22.19-72.endian15
- a) als bash-Schleife:
- altes Kernelmodul-Verzeichnis in /media/sda3/lib/modules sichern und neuere Dateien des neuen Modules kopieren:Code
rsync -av /tmp/modules/* /media/sda3/lib/modules cd /media/sda3/lib/modules mv 2.6.22.19-72.endian15 2.6.22.19-72.endian15.old ln -s 2.6.26-2-686 2.6.22.19-72.endian15
5. Grub installieren: (optional!)
Zunächst sollte man probieren, ob der bereits durch Debian installierte Grub noch funktioniert - einfach neu ohne CD booten 
Falls man die Knoppix-CD zum installieren des grub-loaders verwenden möchte, so hat Knoppix einen Bug, den es vor dem "chrooten" zu berücksichtigen gilt (siehe: http://www.knoppix.net/wiki/Dev_null_permission_denied
Also bei mir musste ich in der Simulation in einer virtuellen Maschinenumgebung den Grub neu installieren. Bei der echten Installation brauchte ich es nicht.
Die gesamte Firewall wurde nun geklont und läuft auf dem Server mit dem Kernel 2.6.26-2-686.
Selbstbeantwortete Fragen: 
- Warum nicht gleich den (viel neueren) Kernel von Knoppix 2.6.28?
Bei Knoppix habe ich keine Boot-Ramdisk (initrd) im /boot gefunden. Es geistert zwar eine minird.gz herum, aber ob die die richtigen Module enthält habe ich nicht überprüft. - Warum erst Debian installieren nur um an den Kernel heranzukommen - kann man den nicht von irgendeiner anderen Maschine schon kopieren?
Man kann nicht sicher sein, ob auch die Treiber/Module für den Zielserver dabei sind. In der manuellen (expert-install) Installation, kann man beispielsweise alles mögliche schon für den Zielserver hereinladen lassen.
Man kann natürlich auch sich den Kernel erst auf einer anderen Maschine bauen, aber ich habe bisher immer kein Erfolg dabei gehabt. - Wie sieht es mit 64Bit-Kerneln aus?
Endian selbst ist ja 32Bit. Da weiß ich nicht, wie die alten gcc-kompillierten Bibliotheken aus /lib mit den neueren Modulen zusammenarbeiten. Was man auf jeden Fall nicht machen sollte, die älteren lib-Dateien mit den neueren Überschreiben - und da beginnt das Dilemma: bei 64Bit gibt es /lib, /lib32 (verlinkt nach /emul/ia32-linux/lib) und /lib64. Da ist bei dem Versuch einiges daneben gegangen.
Falls es bei Endian auch mal eine 64Bit-Version gibt, dürfte dann wohl auch ein 64Bit-Fremdkernel auch möglich sein.
-----------------------------------------
Edit (30.04.2009):
Also bei mir läuft das Ganze jetzt seit 1 Woche auf einem Produktiv-System ohne Ausfälle und ohne andere Probleme. Einzige Ausnahme: Ich kann über das Webfrontend die Passwörter für den Zugriff nicht ändern.
-----------------------------------------
Edit (30.04.2009):
Ok, es liefen auch die anderen cgi-Scripte nicht vernünftig zum Ändern :cry: . Das Problem war, dass der User "nobody" in der alten Version die ID 65534 hatte und somit die FW keinen Schreibzugriff mehr darauf hatte.
Ein Ändern aller 65534:nobody - Dateien auf nobody:nobody brachte Abhilfe und nun kann auch das Webfrontend-PAsswort geändert werden 
cd /
find . -user 65534 -exec chown nobody:nobody {} \;