Absender: Peter Siering
Datum: Fr, 18.11.2005 11:47:07
In-reply-to:
<E1EcnZs-0006sL-D1@xxxxxxxxxxxxxxxxxxxxxx>
On Thu, 17 Nov 2005, Jens Friedrich wrote: > im Forum habe ich im FAQ beschrieben, wie der "UML-IPCop update" > vorgenommen wird. Wie Du sehen kannst, sind wir mit unseren Kerneln im > aktuellen IPCop-1.4.10 mit uml-kernel-2.4.31 angekommen :-) Super. > Wir haben bis dato keine Rückmeldungen über Instabilitäten mit dem > Host-Kernel 2.6 erhalten. Die Downloads unserer Kernel liegen > inzwischen weit über 250 in Summe - denke die gehen. > > Ich habe im Forum ein HowTo geschrieben, wie ich den uml-kernel für > IPCop-1.4.9 gebaut habe, das liest sich soweit analog zu Deiner > Beschreibung. Ich konnte allerdings nicht nachvollziehen, warum ich > den IPCop-UML-Kernel letztlich nur ausserhalb der LFS-IPCop Umgebung > kompilieren konnte :-( > > Denke mein beschrittener Weg ist aber trotzdem sehr sauber. > Er ist im Unterschied zu unserem Ansatz halt ein Stück von dem Weg weg, wie es die IPCop-Entwickler machen. Auf den ersten Blick (hatte bisher nur Zeit die Anleitung zu überfliegen) sieht es so aus, als würdest Du den unter Debian-installierten Compiler fürs Übersetzen des UML-Kernels nutzen; unsser Ansatz nimmt den der IPCop-Build-Umgebung. Ich setze oben auf meine todo-Liste das Experiment mit Deinen Patches, unserer Bau-Umgebung und den alten Testsystemen, mit denen ich die 2.6er-Abstürze perfekt reproduzieren konnte. Das sollte Gewissheit liefern, ob der Compiler womöglich auch Einfluss hat. > Die Frage die sich mir aufdrängt ist, wie oft man ein neues > uml-image-apt paket bauen sollte. Denke das macht man am besten nur > bei Major-Version Changes des IPCop, ansonsten sollte der "normale > update" des IPCop verwendet werden. > Das sollten wir diskutieren - ich hole ein bisschen aus: Wir haben zwei Paketarten geliefert, kleine und große. Die großen jeweils auf der CD inklusive IPCop-ext3-Image-Datei (bz2 komprimiert), die kleinen als Update-Pakete (nur online mit Version 1.1 für Kernel-Update des Pakets auf der CD 1.0). Um das Bauen eines neuen Debian-Pakets kommt man immer dann nicht herum, wenn mit dem IPCop-Update eine Kernel-Aktualisierung einhergeht. Der Kernel der UML-Variante liegt zur Zeit als Binary im Host-Dateisystem, das heißt, aus dem IPCop selbst lässt sich die Datei nicht aktualisieren (es sei denn, man verlegt sie auf eine trickreiche Weise dorthin). Dadurch ist aber das Aktualisieren des IPCop umständlich. Das Debian-Update-Paket muss den IPCop beenden, im ext3-Dateisystem-Image die Modul-Dateien einfügen und im Host-Dateisystem das Kernel-Binary ergänzen und den Cop dann neu starten. Wenn der Vorgang schief geht oder beim Updaten womöglich noch weitere Debian-Pakete nötig sind, kann es im Extremfall passieren, dass der IPCop heruntergefahren ist, aber noch Pakete zu holen wären ;-( Auf den ersten Blick scheint deshalb die Idee gut, das Kernel-Binary ins Image mit hinein zu packen, dann könnte man es bei einem IPCop-internen Update mit austauschen. Man müsse es beim Starten des IPCop dort heraus holen; das könnte man vielleicht durch ein separates Image-File mit dem Kernel und md5sum optimieren. Aber: Ein Neustart aus dem IPCop heraus, lädt ja den Kernel nicht neu, das heißt, man müsste womöglich das init-Skript des Server für den IPCop in einer Schleife kreisen lassen, die schaut, ob sich das boot-image geändert hat, den Kernel dort heraus holt und die UML mit dem neuen Kernel startet. Wäre mir zu heftig ... aber vielleicht gibt es ja noch einen Weg? Die pragmatische Strategie scheint mir deshalb: Bei Kernel-Updates ein Debian-Paket zu bauen. Peter