LZMA-Unterstützung für Kernel 2.6

[dwilx]

Das macht nichts, dann nehmen wir halt "powerpc".

Ist das nur formal zu verstehen, das nur die Bezeichnung weg ist?

[rhabarber1848]

Wenn ich dazu komme, schaue ich mir das mal an.

Wäre es möglich, dass configure_lzma.patch demnächst in CVS wandern könnte?

[seife]

Wenn er so gefixt ist, dass er - möglichst ohne make clean dazwischen - zuverlässig funktioniert, dann schon.
Das ist auf meiner todo-Liste, aber die ist halt lang ;-)

[rhabarber1848]

Wenn er so gefixt ist, dass er - möglichst ohne make clean dazwischen - zuverlässig funktioniert, dann schon.

Das Neubauen der Kernels lässt sich nicht vermeiden, weil der LZMA-Patch so ist, wie er ist
Ein "make clean" scheint aber zu reichen, da neben dem Kernel auch Uboot neugebaut wird, was
wegen der Option CONFIG_SQUASHFS_LZMA wohl ebenfalls nötig ist. Das werde ich aber noch testen...

Fehlt Dir sonst noch etwas an dem Patch, was sich nicht auf den LZMA-Patch als solchem
bezieht? An dessen Einbauweise kann ich leider nichts drehen, dazu reichen meine
Programmierkenntnisse nicht aus.

Wenn configure_lzma.patch im CVS ist, würde ich mich im Anschluss daran setzen, den
LZMA-Support für Kernel 2.6 ebenfalls optional zu machen, damit der dann auch ins CVS
wandern kann

[rhabarber1848]

Wenn er so gefixt ist, dass er - möglichst ohne make clean dazwischen - zuverlässig funktioniert, dann schon.

Ein "make clean" scheint aber zu reichen, da neben dem Kernel auch Uboot neugebaut wird, was
wegen der Option CONFIG_SQUASHFS_LZMA wohl ebenfalls nötig ist. Das werde ich aber noch testen...

Habe den Patch aktualisiert: configure_lzma.patch
Nun wird bei "make clean" mksquashfs mitgelöscht und dadurch
nach nochmaligen configure korrekt neugebaut.

[tcf4004]

So, hab noch bissl mit dem neuen Patch getestet...

CVS 23.06.08, make clean, alle Patches applied (nix rejected), configure --disable-lzma

1. make flash-neutrino-squashfs-all -> läuft durch, beide images ok
2. make flash-clean, make flash-neutrino-jffs2-all -> 2x image hat bad magic bytes, 1x ist ok
3. make flash-clean, make flash-neutrino-squashfs-all -> plötzlich bei beiden images auch bad magic bytes!?

ich wollte eigentlich dann dasselbe nochmal mit make clean+configure --enable-lzma probieren,
hab aber nach 3. aufgehört, weil wie kann es sein dass erst der squashfs-Build durchläuft, dann jffs2-Build
mit bad magics endet (das könnte ja aufgrund der Bytekonstellation noch so sein), und dann ein erneutes squashfs
bauen (ohne irgendwelche Änderungen) plötzlich beim 1x und 2x image bad magic bytes liefert?
Wird evtl. beim jffs2 bauen irgendwas "zersägt" dass sich dann auf folgende Builds auswirkt?

Oder ist ein tagesaktuelles cvs pflicht beim Testen?

[rhabarber1848]

Wird evtl. beim jffs2 bauen irgendwas "zersägt" dass sich dann auf folgende Builds auswirkt?

Das kann nur ein diff der Images von 1. und 3. sagen.

Bei mir ist es so, dass oft das 2x-Squashfs-Image mit "bad magic bytes" angezeigt wird,
obwohl es von der Dbox akzeptiert, gebootet und normal gestartet wird.

[mb405]

jep kann ich zustimmen.
solange die root und 1x images ok sind traue ich mich das 2x zu flashen

[dwilx]

Die Sache mit den Bad magics kann einem schon mal den Spass verderben. Ich habe inzwischen gemerkt, dass es irgendwie mit dem auf dem Host verwendetem Dateisystem (ext3) zu tun haben könnte. Ich hatte da schon X-mal am Stück kaputte Bad-Images. Hatte dann das Host runtergefahren und neu gebootet oder nur mal fsck laufen lassen und siehe da, alles passt. Ist zwar nur eine Vermutung und evtl. nicht objektiv genug, da ich über die Mechanismen im Dateisystem nicht so bescheid weis, aber es hat geholfen.

[rhabarber1848]

solange die root und 1x images ok sind traue ich mich das 2x zu flashen

http://forum.tuxbox-cvs.sourceforge.net ... 42#p309842

Es wird bei 2x-images etwa vier (?) mal so viele Bytes gecheckt. Also kommt "bad magic bytes" viel öfter bei 2x als bei 1x-Images vor.

Können wir davon ausgehen, dass das "bad magic"-Phänomen nichts mit dem LZMA-Patch zu tun hat?
http://forum.tuxbox-cvs.sourceforge.net ... 06#p317806

Checkimage schaut sich bestimmte Byte Konstallationen im Image an, mit dem der Bootloader nicht klar kommt und den Bootvorgang mit "kein System" abbricht. Welche Daten (Filesystem etc) in dem Image sind ist hier egal.

Ich würde vorschlagen, dass "bad magic"-Problem in den passenden Threads weiter
zu diskutieren. Wenn sonst niemand mehr Probleme/Verbesserungsvorschläge zum
configure_lzma-Patch hat, steht dessen Aufnahme ins CVS nichts mehr entgegen, oder?

[tcf4004]

Wenn ich Zeit habe werde ich obigen Test nochmal ohne flash-clean, dafür mit make clean
jeweils ausführen. Mir geht es erstmal nur um folgendes:

Man hat eine Buildumgebung und kann die Kommandos

make flash-clean
make flash-neutrino-xxx-all

normalerweise beliebig wiederholen (egal ob jffs2 oder squashfs) ohne dass es bad magics
gibt. Das komische bei dem Patch hier ist ja folgendes: erstmaliges Erstellen ist ok, aber dann
nach dem 2. make flash-clean und erneutem Erstellen scheint irgendwas anders abzulaufen.
DAS hatte ich bisher noch nie festgestellt.

Aber das Thema bad magics ist sehr komplex, und lzma hat nicht direkt was damit zu tun.
Es werden halt nur bestimmte Bytefolgen erzeugt die den Fehler hervorrufen.
dboxshot ist auch so ein programm, wenn ich das mit reinpacke, hab ich fast schon die
Garantie dass bad magics kommen. Auch hier liegt es nicht am Programm selber, sondern
an den Bytekonstellationen im dboxshot-Compilat bzw. an der Position bestimmter Bytes im Image.

Ist halt nur immer sehr stressig herauszufinden wo sich die bad magics befinden, dann wieder Dummys reinkopieren,
neu bauen usw. Da sind (wohl nicht nur bei mir) schon einige Stunden draufgegangen.

[tcf4004]

Habe gerade gesehen, den Test mit make clean hätte ich mir sparen können,
denn der mksquashfs build ist ja im Target flash-clean gepatcht...

Code: Alles auswählen

diff -uNr ../cvs/cdk/make/cleantargets.mk ./cdk/make/cleantargets.mk
--- ../cvs/cdk/make/cleantargets.mk	2007-11-07 12:27:21.000000000 +0100
+++ ./cdk/make/cleantargets.mk	2008-07-06 17:35:04.000000000 +0200
@@ -150,6 +150,7 @@
 
 flash-clean: flash-mostlyclean
 	rm -f $(flashprefix)/*.img*
+	rm -f $(hostprefix)/bin/mksquashfs
 endif ## TARGETRULESET_FLASH
 
 .PHONY: depsclean mostlyclean-local cdk-clean distclean-local flash-semiclean \

Denn make flash-clean löscht ja nur alles in $(flashprefix), während make clean
eine Kombination aus depsclean, mostlyclean und flash-clean ist, wenn
ich mich nicht irre... Entsprechend länger dauert ein Build nach
einem make clean, während Builds nach einem flash-clean nur ca. 15 Minuten
benötigen.

ok, das heisst also nach make flash-clean und anschliessendem rebuild
müsste nun alles korrekt neu gebaut werden? Nur dass ich nix unsinniges teste

Ich werde nochmal in einer neuen Buildumgebung ganz neu auschecken, die
Patches applizieren, configuren mit --disable-lzma und dann folgendes machen:

Code: Alles auswählen

make flash-neutrino-squashfs-all -> 1. build squashfs
make flash-clean                 -> $(flashprefix) cleanup
make flash-neutrino-jffs2-all    -> 2. build jffs2
make flash-clean                 -> $(flashprefix) cleanup
make flash-neutrino-squashfs-all -> 3. build squashfs

Am besten ganz ohne customization und natürlich ohne jeweils zwischen den Builds
irgendwas zu ändern. Und wenn dann bei Build 3 wieder bad magics kommen obwohl
Build 1 korrekt durchgelaufen ist, tja dann weiss ich auch nicht...

Mit den bad magics bei jffs2 hatte ich auch schonmal bei absolut gesetzten Links,
die während des Builds keinen Bezug zur Zieldatei hatten. Der Link wurde dann nicht
erstellt und es traten bad magics auf. Setze ich den Link aber relativ ../xxx/
dann gehts. In den Patches sind ja keine ln's drin, das kanns also nicht sein,
sollte auch nur so ein Einwurf von mir sein, dass die bad magics manchmal von den
"dollsten Dingern" kommen

[rhabarber1848]

ok, das heisst also nach make flash-clean und anschliessendem rebuild
müsste nun alles korrekt neu gebaut werden?

Nein.
"make flash-clean" ist eine Untermenge von "make clean". "make clean" ist
weiterhin erforderlich, da eine Änderung des LZMA-Configure-Parameters
die Neukompilierung des Kernels und Uboots erfordert.

[tcf4004]

ok, um erstmal nicht zu sehr in die bad magic bytes-Problematik abzudriften und
die eigentliche Funktionalität zu testen, habe ich mir das so gedacht:

Test1 (lzma-patch disable/enable)
------------------------------------------
1. neuestes cvs auschecken, patchen, configure --disable-lzma
2. squashfs erzeugen
3. make clean, configure --enable-lzma
4. squashfs (mit lzma) erzeugen
5. rootgrössen vgl. und Images testen
6. Ergebnisse hier posten

Kann aber nen Moment dauern

[rhabarber1848]

1. neuestes cvs auschecken, patchen, configure --disable-lzma
2. squashfs erzeugen
3. make clean, configure --enable-lzma
4. squashfs (mit lzma) erzeugen
5. rootgrössen vgl. und Images testen

Genau das habe ich in den letzten Tagen gemacht, abgesehen von der "bad magic"-
Geschichte funktionierten alle Neutrino/Enigma-Squashfs-Images mit/ohne LZMA.
"make clean" leistet dabei gute Dienste.

[tcf4004]

Testparcours noch etwas erweitert:

Code: Alles auswählen

1. neuestes cvs auschecken, patchen, configure --disable-lzma
2. squashfs erzeugen                    -> OK (5.2mb)
3. make clean, configure --enable-lzma
4. squashfs (mit lzma) erzeugen         -> OK (4.3mb)
5. make clean, configure --enable-lzma
6. jffs2 erzeugen                       -> OK

Keine bad magics mehr und Images laufen einwandfrei, sogar jffs2
Obs aber nun am neueren cvs, an make clean oder an der nun fehlenden
customization liegt, vermag ich nicht zu sagen.

Ich mach für heute Feierabend

[seife]

Ich habe eine leicht veränderte Version des Patchs eingecheckt.
Änderungen:
- mksquashfs-lzma oder mksquashfs-nolzma, deswegen muss es bei "make flash-clean" nicht entfernt werden
- kernel 2.6 build ohne "--disable-lzma" bricht ab (noch ist der 2.6er-Support nicht drin)

Hoffentlich habe ich sonst nichts kaputtgemacht

[rhabarber1848]

Ich habe eine leicht veränderte Version des Patchs eingecheckt.

Danke, Kernel 2.4-Images mit und ohne LZMA funktionieren.

Hier ein experimenteller Patch für LZMA-Support im Kernel 2.6: kernel26_lzma8.diff

Ich konnte noch nicht viel testen, möchte es aber schon mal
der Allgemeinheit zur Verfügung stellen
Der Squashfs-Code von mohousch ist unverändert geblieben, nur die
make-files habe ich ein wenig ans aktuelle CVS angepasst.

Außerdem ist (ungetestet) noch ein kleiner Patch drin, damit
aus der beim Booten vom Kernel angezeigten Partitionstabelle
ersichtlich ist, ob LZMA genutzt wird oder nicht.

[rhabarber1848]

Hier ein experimenteller Patch für LZMA-Support im Kernel 2.6: kernel26_lzma8.diff

Patch aktualisiert, Status weiterhin experimentell. Für U-Boot fehlte noch ein Patch.

EDIT: LZMA-2.6-Image bootet jetzt normal, allerdings ist die Partitionsanzeige noch fehlerhaft.

0x00040000-0x00500000 : "root ()"

Ich arbeite dran Tests mit 2.6 ohne LZMA stehen auch noch an.

[rhabarber1848]

allerdings ist die Partitionsanzeige noch fehlerhaft.

0x00040000-0x00500000 : "root ()"

Das ist in der aktuellen Version des Patches gelöst:

0x00040000-0x00500000 : "root (squashfs+lzma)"

Tests mit 2.6 ohne LZMA stehen auch noch an.

Die habe ich schon gemacht und bin dabei auf ein Problem gestoßen.

Für Kernel 2.4 reicht es, die Option CONFIG_SQUASHFS_LZMA in der Kernel .config
zu ändern. Bei Kernel 2.6, mit den vorhandenen Patches, geht das nicht.
Der Kernel 2.6-LZMA-Patch, der ebenfalls die Squashfs-Funktionalität enthält,
von mohousch läßt das Abschalten der LZMA-Funktion, soweit ich das sehe,
nicht zu. Ein "make clean" reicht auch nicht aus, da der Kernel nicht neu
entpackt/gepatcht wird.

Wenn nun ein Image mit enable-lzma, dann make clean, dann ein weiteres
Image mit disable-lzma gebaut wird, startet letzteres nicht mehr, da der
Kernel LZMA erwartet, obwohl es nicht vorhanden ist.

Kann jemand anderes diesen Bug nachvollziehen und hat vielleicht sogar
eine Lösung dafür?

[rhabarber1848]

Ich habe damit begonnen, den LZMA-Support für Kernel 2.6 optional zu machen.

Hier ist mein aktueller Arbeitsstand, er nutzt Squashfs 3.0 anstatt 3.3, genauso
wie der Patch von mohousch. U-Boot unterstützt leider kein LZMA mit Squashfs 3.3,
sondern nur in Verbindung mit Squashfs 3.0. Der Patch von mohousch nutzt
Squashfs 3.0, allerdings auf eine Art und Weise, welche die optionale Nutzung
von LZMA erschwert.

Ich habe daher angefangen, den LZMA-Anteil aus mohouschs Patch zu entfernen
und mit minimalen Patches den Original-Squashfs 3.0-Patch für Kernel 2.6.25.6 anzupassen.

Basierend auf dem Originalpatch (squashfs3.0/linux-2.6.15/squashfs3.0-patch) aus
squashfs3.0.tar.gz enthält mein Patch zwei Patches:

linux-2.6.25-squashfs3.0.diff
Damit wird o.g. Originalpatch so verändert, dass er mit Kernel 2.6.25.6 nutzbar ist.

Dann wird der Originalpatch squashfs3.0-patch in den Kernel 2.6.25.6-Sourcecode integriert.

linux-2.6.25.6-squashfs3.0.diff
Dieser Patch enthält die nötigen Anpassungen für den Originalpatch, der ursprünglich
für Kernel 2.6.15 gedacht ist, damit er mit Kernel 2.6.25.6 kompiliert. Nachdem der
Originalpatch im Kernel-Sourcecode integriert ist, wird nun dieser Patch integriert.

Die bisher genutzte Datei cdk/Patches/linux-2.6.25-squashfs3.3.patch ist überflüssig
und kann, wenn mein Patch im CVS ist, aus selbigem entfernt werden.

Ein mit meinem Patch kompilierter Kernel (2.6.25.6, Squashfs 3.0) funktioniert.
Bitte testet meinen Patch (--enable-kernel26 --disable-lzma) und gebt mir Rückmeldungen.

Hier der Link zum Patch: kernel26_squashfs30.diff

Als nächstes kommt nun der LZMA-Teil...

[rhabarber1848]

Hier der Link zum Patch: kernel26_squashfs30.diff

Als nächstes kommt nun der LZMA-Teil...

So, LZMA ist fertig und funktioniert.
Bitte den o.g. Patch nochmal herunterladen, es gab kleine Änderungen.

Nach dem o.g. Patch nun diesen Patch anwenden: kernel26_lzma11.diff
und ein Image mit --enable-kernel26 kompilieren, LZMA ist per default aktiviert.
Danach, wenn ihr Zeit und Lust habt, mit --disable-lzma kompilieren und testen.

Hier die Unterschiede:

mit LZMA

Code: Alles auswählen

-rw-r--r--  1 root root 4923392 14. Jul 23:40 root-neutrino.squashfs

   Image Name:   Linux-2.6.25.6-dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    987078 Bytes = 963.9 kB

squashfs: version 3.0 (2006/03/15) / LZMA enabled Phillip Lougher

Creating 6 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "FLFS (U-Boot)"
0x00040000-0x006a0000 : "root (squashfs+lzma)"
0x006a0000-0x00800000 : "var (JFFS2)"
0x00020000-0x00800000 : "Flash without bootloader"
0x00000000-0x00800000 : "Complete Flash"

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock/2           4.8M      4.8M         0 100% /
/dev/mtdblock/3           1.4M    920.0k    488.0k  65% /var

ohne LZMA

Code: Alles auswählen

-rw-r--r--  1 root root 5656576 15. Jul 16:27 root-neutrino.squashfs

   Image Name:   Linux-2.6.25.6-dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    985524 Bytes = 962.4 kB

squashfs: version 3.0 (2006/03/15) Phillip Lougher

Creating 6 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "FLFS (U-Boot)"
0x00040000-0x006a0000 : "root (squashfs)"
0x006a0000-0x00800000 : "var (JFFS2)"
0x00020000-0x00800000 : "Flash without bootloader"
0x00000000-0x00800000 : "Complete Flash"

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock/2           5.6M      5.6M         0 100% /
/dev/mtdblock/3           1.4M    868.0k    540.0k  62% /var

[seife]

Wenn ich die Patches so sehe, müsste es auch gehen, zur Laufzeit zu entscheiden ob LZMA oder nicht. Das hätte den Vorteil, dass der Kernel beide Versionen verarbeiten könnte und nur noch das mksquashfs angepasst werden müsste...
...dummerweise werde ich in absehbarer Zeit nicht dazu kommen, das auszuprobieren...

[rhabarber1848]

zur Laufzeit zu entscheiden ob LZMA oder nicht.

Ein LZMA-Kernel kann auch in einem nicht-LZMA-Squashfs genutzt werden,
das Herausoperieren von CONFIG_SQUASHFS_LZMA aus der Kernel-.config
habe ich erst später eingebaut, der Vollständigkeit halber

Die Frage ist nur, ob U-Boot bei gesetztem CONFIG_SQUASHFS_LZMA
ein nicht-LZMA-Image booten kann. Ich glaube es eher nicht, wenn ich
Code wie diesen hier sehe (u-boot-tuxbox/fs/squashfs/uncompress.c

Code: Alles auswählen

#ifdef CONFIG_SQUASHFS_LZMA
#include "LzmaDecode.h"
#include "LzmaDecode.c"
static CLzmaDecoderState state;
#else
#include <zlib.h>
static z_stream stream;
#endif

Aber ich werde das mal testen...

[seife]

zur Laufzeit zu entscheiden ob LZMA oder nicht.

Ein LZMA-Kernel kann auch in einem nicht-LZMA-Squashfs genutzt werden,
das Herausoperieren von CONFIG_SQUASHFS_LZMA aus der Kernel-.config
habe ich erst später eingebaut, der Vollständigkeit halber

Bist du sicher / hast du das probiert? Weil das:

Code: Alles auswählen

+#ifdef CONFIG_SQUASHFS_LZMA
+static unsigned char lzma_workspace[LZMA_WORKSPACE_SIZE];
+#else
 static z_stream stream;
+#endif

sieht ähnlich wie beim u-boot aus.

Die Frage ist nur, ob U-Boot bei gesetztem CONFIG_SQUASHFS_LZMA
ein nicht-LZMA-Image booten kann. Ich glaube es eher nicht, wenn ich
Code wie diesen hier sehe (u-boot-tuxbox/fs/squashfs/uncompress.c

Code: Alles auswählen

#ifdef CONFIG_SQUASHFS_LZMA
#include "LzmaDecode.h"
#include "LzmaDecode.c"
static CLzmaDecoderState state;
#else
#include <zlib.h>
static z_stream stream;
#endif

Aber ich werde das mal testen...

Man könnte ja den Kernel in eine extra cramfs-Partition machen (das verschenkt allerdings Platz, weil die Partition immer etwas grösser sein wird, als unbedingt notwendig), oder gleich nach /var, das dann entsprechend grösser wäre.
Wirklich komprimieren lässt sich das Kernel-image eh nicht.
Im /var wäre halt die Gefahr, dass irgendein Knollo beim Aufräumen den Kernel löscht, "weil der soviel Platz braucht", aber der wäre dann halt selbst schuld.

Teste mal, ich bin gespannt auf die Ergebnisse