2.6.33.3-qx2

[Manfred]

BP > 2.6.xx = Backport from/von lower/älterer Version
BP < 2.6.xx = Backport from/von higher/neuerer Version
KP = Patch from/von lkml/kernel.org
CP = Custom/eigenes Patch
VP = Vendor/Hersteller Patch
Status:  

New Module(s)/Features:

• aufs2 - VP (aufs.sf.net) / CP (Quax)
• sqlzma 3.4 - VP (squashfs-lzma.org) / CP (Quax)

             Dank 'fanthom' aus dem Slax-Forum sind aufs2/sqlzma wieder als Module kompiliert.
             Thanks to 'fanthom' from Slax forum aufs2/sqlzma are compiled as modules again.

• vmware-balloon - KP < 2.6.34-rc6
• kaweth - KP (Allied Telesyn AT-USB10) < 2.6.34-rc6

Settings/Einstellungen:

• devtmpfs (udev)
• CONFIG_LBDAF=y (ext4) - Thanks to Marc from http://pureos.org
• ..

Auf Grund dieser und anderer Änderungen ist dieser Kernel erheblich kleiner und schneller geworden
Due to this and other changes/settings the kernel has become much faster and smaller

Gruss/Regards,

Quax

[GNC]

Hallo Quax,

ist dieser Kernel FFSL-tauglich, kann ich ihn in Fluxflux-SL 2009.3 verwenden?

Auf Grund dieser und anderer Änderungen ist dieser Kernel erheblich kleiner und schneller geworden. 

Bezieht sich diese Aussage auf den bisher bei Fluxflux-SL eingesetzt Kernel 2.6.30.9-qx1?

Gruss aus dem nun wieder sonnigen Frankfurt,
GNC

[Manfred]

Hallo GNC,

...ist dieser Kernel FFSL-tauglich, kann ich ihn in Fluxflux-SL 2009.3 verwenden?...

Ja ist er, kannst Du im installierten System

Gruss, Quax

[GNC]

Hallo Quax,

treffen die beiden Aussagen, auch auf den auf Lin2Go bereit gestellten Kernel 2.6.34 zu?

Gruss GNC

[Manfred]

Hallo GNC,

...treffen die beiden Aussagen, auch auf den auf Lin2Go bereit gestellten Kernel 2.6.34 zu?

Alle Kernel-(Quellen), welche wir anbieten, sind auf installierten Systemen getestet - Also auch der 34er

Für eine Live-Version sind sie NUR BEI MANUELLER ERSTELLUNG DER INITRD einsetzbar.

Gruss, Quax

[GNC]

Hallo Quax,

ich hatte ohnehin vor, diese Kernel zusätzlich zum schon vorhandenen Kernel 2.6.30.9-qx1 auf installierten Systemen einzusetzen. Ich habe vor, die Kernelquellen komplett neu zu übersetzen und manueller Installation ein TGZ-Paket zu bauen.

Vielen Dank für die prompte Info und schönen Gruss
GNC

[Manfred]

Hallo GNC,

...ein TGZ-Paket zu bauen...

In /usr/src/lmobuilds/qx-kernelxxx findest Du die Build-Skripte, mit denen Du VON EINEM BEREITS IM SYSTEM INSTALLIERTEN KERNEL die Pakete in der gleichen Art erstellen kannst, wie wir sie für FFSL nutzen.

Gruss, Quax

[prajwal]

Is the kernel 2.6.34 patched with squashfs+lzma??

[Manfred]

Hi Prajwal,

yes, it is - With squashfs3.4 + lzma from linux-live.org

Regards, Quax

[GNC]

Hallo Quax,

gibt es für die Kernel 2.6.33 und 2.6.34 schon vorbereitete ".config"-Dateien, um die neuen Kernel weitestgehend analog zun Kernel 2.6.30.9-qx1 zu konfigurieren? Oder kann man die Konfiguration der Kernels 2.6.30.9-qx1 als Ausgangsbasis zur Konfiguration der neuen Kernel verwenden?

Die unter "/usr/src/lmobuilds/qx-kernelxxx" vorgefundenen Skripte bauen separate Pakete für den eigentlichen Kernel, die Module und Firmware. Ich tendiere dazu, zumindest Kernel und Module in ein Paket zu packen. Da sich die Dateien einer Kernelversion im Namen von anderen Kernelversionen unterscheiden und auch die Module in versionsspezifischen Verzeichnissen unterhalb "/lib/modules" zu liegen kommen, kann ich verschiedene Kernelversionen auf einem System installieren.

Die Firmware-Dateien der Kernel landen immer in "/lib/firmware". Damit werden vorhandene Firmware-Dateien überschrieben. Bisher habe ich immer die Erfahrung gemacht, dass Hardware, die unter einem vorhandenen Kernel mit seinen zugehörigen Firmware-Dateien funktioniert, auch mit einem neueren Kernel läuft, ohne das dessen Firmware-Dateien mit installiert werden.

Ist es denn so, wenn ich einen Kernel 2.6.33 oder 2.6.34 mit den zugehörigen Firmware-Dateien installiere, auch der bisherige Kernel 2.6.30.9-qx1 mit den neueren Firmware-Dateien zusammenspielt?

Gruss aus Ffm unter Ffsl,
GNC

[Manfred]

... gibt es für die Kernel 2.6.33 und 2.6.34 schon vorbereitete ".config"-Dateien, um die neuen Kernel weitestgehend analog zun Kernel 2.6.30.9-qx1 zu konfigurieren? Oder kann man die Konfiguration der Kernels 2.6.30.9-qx1 als Ausgangsbasis zur Konfiguration der neuen Kernel verwenden?

Meine Kernel haben zur Laufzeit alle die Konfiguration in /proc/config.gz parat.

Im laufenden System kompiliere ich immer nach folgendem Schema:

• cd /usr/src/<neuer-kernel>
• zcat /proc/config.gz > .config
• make prepare && make scripts
• make oldconfig
• make menuconfig

Ich sehe es genau so wie Du, dass man immer die aktuelle, funktionierende Konfiguration als Basis für einen neuen
Kernel nehmen sollte.

Ich tendiere dazu, zumindest Kernel und Module in ein Paket zu packen. Da sich die Dateien einer Kernelversion im Namen von anderen Kernelversionen unterscheiden und auch die Module in versionsspezifischen Verzeichnissen unterhalb "/lib/modules" zu liegen kommen, kann ich verschiedene Kernelversionen auf einem System installieren.

Das kannst Du halten wie die Dachdecker - Das Aufteilen des Kernels in eigene Pakete in FFSL ist bedingt durch
den Wunsch nach mehr Flexibilität.

Die Firmware-Dateien der Kernel landen immer in "/lib/firmware". Damit werden vorhandene Firmware-Dateien überschrieben. Bisher habe ich immer die Erfahrung gemacht, dass Hardware, die unter einem vorhandenen Kernel mit seinen zugehörigen Firmware-Dateien funktioniert, auch mit einem neueren Kernel läuft, ohne das dessen Firmware-Dateien mit installiert werden.

In den meisten Fällen hast Du hier Recht.

Ist es denn so, wenn ich einen Kernel 2.6.33 oder 2.6.34 mit den zugehörigen Firmware-Dateien installiere, auch der bisherige Kernel 2.6.30.9-qx1 mit den neueren Firmware-Dateien zusammenspielt?

Das kommt auf die Firmware an - Wenn diese in der neueren Version auch neuere Funktionen bietet, kann es schon
'mal passieren, dass die Treiber älterer Kernel nicht mehr funktionieren.

Da flux und ich als Distributoren auf Zuverlässigkeit mehr Wert legen müssen, ist auch das ein Grund für das Aufteilen der Pakete. So kann man gegebenenfalls eine ältere Firmware manuell in ein neueres Paket integrieren.

Gruss, Quax