Kernel 2.4.26

[krombacher]

Hallo, da ich gestern Nacht nicht einschlafen konnte, habe ich mal ausprobiert, ob man nicht auch einfach Kernel 2.4.26 statt 2.4.25 verwenden kann. So wie's aussieht funktioniert das problemlos. An den patches muss nichts verändert werden (außer, dass SUBLEVEL natürlich von 25 auf 26 geändert werden muss) und der neue Kernel läuft bis jetzt einwandfrei.
Als ich dann schon mal dabei war, hab ich auch auf squashfs2.0 upgedatet. Beim Kernel, weiß ich jetzt nicht, ob die neue Version Vorteile bringt, aber squashfs2.0 soll sogar wirklich was bringen (12% bessere Komprimierung durch fragment blocks)
Würde es Sinn machen, das auch im CVS zu ändern???

[Sat_Man]

Als ich dann schon mal dabei war, hab ich auch auf squashfs2.0 upgedatet. Beim Kernel, weiß ich jetzt nicht, ob die neue Version Vorteile bringt, aber squashfs2.0 soll sogar wirklich was bringen (12% bessere Komprimierung durch fragment blocks)
Würde es Sinn machen, das auch im CVS zu ändern???

IIRC müsste für Squashfs 2.0 erst mal u-boot angepasst werden, vorher macht es keinen Sinn das einzubauen.

[krombacher]

Wieso müsste u-boot angepasst werden? u-boot kam doch mit dem alten squashfs (welche Version war das jetzt? 1.3, oder so) auch nicht klar. Deshalb liegt der Kernel ja auch im cramfs. Wäre natürlich nett, wenn jemand u-boot anpassen könnte, so dass man auf cramfs komplett verzichten könnte, aber squashfs2.0 funktioniert auch so.
Zumindest habe ich meinen Kernel mit squashfs2.0 gepatcht, und auch das neue mksquashfs benutzt.
Kann man sich irgendwie anzeigen lassen, ob wirklich squashfs2.0 verwendet wird???

[Sat_Man]

Wieso müsste u-boot angepasst werden? u-boot kam doch mit dem alten squashfs (welche Version war das jetzt? 1.3, oder so) auch nicht klar. Deshalb liegt der Kernel ja auch im cramfs.

Richtig

Wäre natürlich nett, wenn jemand u-boot anpassen könnte, so dass man auf cramfs komplett verzichten könnte, aber squashfs2.0 funktioniert auch so.

Das wäre das einzig sinnvolle und darauf bezog sich mein vorheriges posting auch.
Den Kernel in einer cramfs partition auszulagern und zusätzlich squashfs als root partition ist imho unsinnig, weil man dann eine weitere Partition hätte.
Das alte squashfs hatte auch keine CRC und war somit imho für die Flash Funktionen von neutrino und enigma vollkommen ungeeignet und deswegen auch nicht default im CVS gesetzt.
Die flash Funktion von neutrino und enigma müsste dann erst angepasst werden.
Dies müsste natürlich auch gemacht werden wenn man cramfs komplett durch squashfs 2.0 ersetzen würde, aber ich finde erst dann ergibt der ganze Aufwand einen Sinn, weil in squashfs 2.0 wohl eine CRC drin sein soll.
Die libcramfs müsste dann natürlich auch um squashfs erweitert werden.

[chkbox]

Das alte squashfs hatte auch keine CRC und war somit imho für die Flash Funktionen von neutrino und enigma vollkommen ungeeignet und deswegen auch nicht default im CVS gesetzt.

Und was bedeutet dann

Yadi Squashfs 2x 7.88MB 30.05.2004 23:56 1.8.1.0 Tuxbox Head - SquashFS 2x

? Sieht für mich so aus, als ob squashfs eingesetzt wird. Außerdem verstehe ich nicht ganz, wieso CRC im FS für die Flash-Funktion der GUIs wichtig sein soll. Wurde nicht mit MD5 geprüft, ob der Download OK ist und dann geflasht? Und auch bei Methoden wie cat ... und fcp wird nicht geprüft, ob der Kopiervorgang erfolgreich war. Letztendlich braucht man ja auch nur den Bmon zum Flashen. Also wofür CRC beim Flashen?

[krombacher]

Ok, ich glaub, jetzt hab ich Dich verstanden
Ich will garnicht, dass squashfs2.0 jetzt standardmäßig verwendet wird. Aber bisher wird der Kernel im cdk mit squashfs1.3r3 gepatcht. Da jetzt squashfs2.0 verfügbar ist, könnte man ja auch einfach das verwenden.
Und völlig unsinnig finde ich es auch nicht cramfs UND squashfs zu verwenden. Mache ich schon so, seitdem es die Anleitung von lucgas gibt. Komprimiert halt besser als cramfs. Die Yadi-Images gibt's ja auch als squashfs images. Ich denke mal - falls die keinen geheimen u-boot haben - dass dort auch squashfs+cramfs verwendet wird.

Edit: Verdammt, schreibe ich wirklich so langsam? chkbox hat ja auch die yadi images angesprochen...

[chkbox]

Code: Alles auswählen

### FS (jffs2) loading 'vmlinuz' to 0x100000
Scanning JFFS2 FS: . done.
### FS load complete: 610182 bytes loaded to 0x100000
...............................................................
Un-Protected 63 sectors
## Booting image at 00100000 ...
   Image Name:   dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    610118 Bytes = 595.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.4.25-dbox2 (ImageTeam@yadi.org) (gcc version 3.3.3) 
[...]
Creating 7 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "flfs (u-boot)"
0x00040000-0x000e0000 : "kernel (jffs2)"
0x000e0000-0x006a0000 : "root (squashfs)"
0x006a0000-0x00800000 : "var (jffs2)"
0x00020000-0x00800000 : "flash without bootloader"
0x00000000-0x00800000 : "complete flash"

In den Yadis wird offenscihtlich squashfs fürs root und jffs2 für den Kernel benutzt. Ist eigentlich auch sinnvoll, den jffs2 muss für /var eh als Treiber vorhaden sein.

[Npq]

Also wofür CRC beim Flashen?

Das habe ich mich auch gefragt, liegt wohl daran, daß keiner die Routinen entsprechend erweitern konnte/wollte, daß man nicht auf den CRC-Check des FS zurückgreifen mußte.

Aber es ist schon sinnvoller, wenn auch während des Betriebs eine CRC-Überprüfung stattfindet.

Von daher ist das 2.0er SquashFS sicherlich schon unterstützenswert.

[chkbox]

Das habe ich mich auch gefragt, liegt wohl daran, daß keiner die Routinen entsprechend erweitern konnte/wollte, daß man nicht auf den CRC-Check des FS zurückgreifen mußte.

Verstehe trotzdem nicht, was Flashen und CRC im FS mit einander zu tun haben. CRCs im FS machen doch nur Sinn, wenn sie für jede Datei gespeichert werden. Bei Flashen ist es aber sinnvoller, das ganze Image zu testen und genau das macht zumindest Enigma ja auch mit MD5. http://yadi.org/update/squashfs_catalog.xml liefert die Update Liste und MD5 zum Testen des Downloads. Also, könnte mir jemand sagen, was man mit CRC beim Flashen machen kann?

Aber es ist schon sinnvoller, wenn auch während des Betriebs eine CRC-Überprüfung stattfindet.

Von daher ist das 2.0er SquashFS sicherlich schon unterstützenswert.

Stimme ich nicht ganz zu, weil das den Nachteil hätte, dass die Lesegeschwindigkeit abnimmt. Da der Flash eigentlich nur beim Flashen kapput gehen kann und nicht beim lesen, muss man doch nur testen, ob das Image richtig geschrieben wurde. Oder?

[Npq]

Ah, da hat wer nicht in die Sourcen geschaut *g*.

Nein, ist ganz einfach, cramfs speichert im Header eine CRC über das gesamte Dateisystem (ist ja nunmal read-only, also ändert sich das auch nicht). Neutrino checkt einfach mit Hilfe einer cramfs-eigenen Implementierung, ob die Checksumme zum Image paßt.

Bei squashfs müßte man das halt extra machen und dafür gab's keinen Code in Neutrino.

Mir sind durchaus schon Bits im Flash während des Betriebs gekippt, sogar (bei der 1er) mal in die falsche Richtung, aber frag' mich nicht wieso.

[Sat_Man]

Code: Alles auswählen

### FS (jffs2) loading 'vmlinuz' to 0x100000
Scanning JFFS2 FS: . done.
### FS load complete: 610182 bytes loaded to 0x100000
...............................................................
Un-Protected 63 sectors
## Booting image at 00100000 ...
   Image Name:   dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    610118 Bytes = 595.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.4.25-dbox2 (ImageTeam@yadi.org) (gcc version 3.3.3) 
[...]
Creating 7 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "flfs (u-boot)"
0x00040000-0x000e0000 : "kernel (jffs2)"
0x000e0000-0x006a0000 : "root (squashfs)"
0x006a0000-0x00800000 : "var (jffs2)"
0x00020000-0x00800000 : "flash without bootloader"
0x00000000-0x00800000 : "complete flash"

In den Yadis wird offenscihtlich squashfs fürs root und jffs2 für den Kernel benutzt. Ist eigentlich auch sinnvoll, den jffs2 muss für /var eh als Treiber vorhaden sein.

Ok, also zur Prüfsumme hat Npq ja schon ausreichend Infos geliefert, ich habe dem eigentlich nichts hinzuzufügen.
Das im yadi Image seit kurzer Zeit cramfs komplett durch squashfs ersetzt werden konnte liegt daran, dass ein freundlicher Dev, u-boot beigebracht hat squashfs booten zu können.
Vorher hatten sie den Kernel in einer cramfs Partition liegen.
Diese u-boot Anpassung müsste halt jetzt für das neue squashfs 2.0 wieder einer machen.
Eine richtige CRC Prüfung ist also momentan nicht in den yadi images enthalten, soweit ich weiß wird dort noch das alte squashfs 1.3 eingesetzt.
Die flash Funktionen werden halt auch von newbies verwendet, Funktionen wie cat und fcp kennen newbies im Normalfall gar nicht.
Ich finde das schon ganz Sinnvoll auf ein funktionierendes squashfs 2.0 zu warten.
Wie gesagt, dass ist meine persönliche Meinung, was das yadi Team macht ist halt ihre Entscheidung.

[essu]

In den Yadis wird offenscihtlich squashfs fürs root und jffs2 für den Kernel benutzt.

yep

[...]soweit ich weiß wird dort noch das alte squashfs 1.3 eingesetzt.
Die flash Funktionen werden halt auch von newbies verwendet, Funktionen wie cat und fcp kennen newbies im Normalfall gar nicht.

yousa, deshalb ist (leider) auch internet-update unter Neutrino deaktiviert

Ich finde das schon ganz Sinnvoll auf ein funktionierendes squashfs 2.0 zu warten.
Wie gesagt, dass ist meine persönliche Meinung, was das yadi Team macht ist halt ihre Entscheidung.

Funktioniert squashfs 2.0 nun oder nicht? Allein die bessere Kompression hätte für Yadi_images mit zwei GUIs natürlich ihren Reiz, wenn Kernel dann noch im squashfs sein könnte, wäre es natürlich perfekt. Ich denke squashfs hat sich entgegen anfänglichen Bedenken als stabil und schnell erwiesen und wenn es Verbesserungen in diesem Bereich gibt sollte man die auch für dbox2 nutzen. Aber überstürzen werden wir auch nichts.

[krombacher]

Funktioniert squashfs 2.0 nun oder nicht?

Also bei mir läuft's seit gestern problemlos. Und auf http://squashfs.sourceforge.net/ steht auch nix davon, dass das unstable oder experimentell ist. Und überstürzen müsst Ihr ja auch nichts. Ihr könnt es doch einfach mal ausprobieren. Ist ja nur ein anderer Kernelpatch und mksquashfs neu kompilieren. Und das image wird tatsächlich kleiner. Bei mir 200kb...
Wenn das dann in den Yadi Images läuft, kann's vielleicht auch offiziell im cvs übernommen werden?!?
Und was ist denn jetzt mit u-boot? Sat_Man schreibt, dass u-boot jetzt squashfs booten kann, aber essu bestätigt, dass für den Kernel jffs2 verwendet wird... Also geht squashfs doch immer noch nicht???

[mws]

hi,

mal ne frage nebenher.

wieviel spart squash fs jetzt eigentlich ein?
hat mal jmd nen test gemacht zwischen der cramfs und squashfs unter berücksichtung einmal ohne squash kernelpatch und einmal mit?

gruss
mws

[krombacher]

Was meinst du denn jetzt mit "einmal mit und einmal ohne kernelpatch" ?
Ich hab normalerweise folgende Aufteilung: Kernel im cramfs, etc-zeugs im jffs2 und Rest im squashfs. Ich hab jetzt mal grad nen Vergleich gemacht, und den "Rest" in squashfs2.0 und 1.3, und cramfs gepackt:

Squashfs2.0 - 4.4 MB
Squashfs1.3 - 4.6 MB
Cramfs - 5.1 MB

[mws]

naja
ich meine damit den kernel OHNE squashfsunterstützung.

gruss
mws

[JtG-Riker]

hi,

mal ne frage nebenher.

wieviel spart squash fs jetzt eigentlich ein?
hat mal jmd nen test gemacht zwischen der cramfs und squashfs unter berücksichtung einmal ohne squash kernelpatch und einmal mit?

gruss
mws

also bei einem vollen Imave von ca 6,9MB waren es ca 700kb weniger bei Squashfs 1.3- das hatte ich mal getestet.

Ich habe unter anderem wegen den fehlendem CRC auch bis jetzt davon abgesehen Squashfs ins JTG Image zu übernehmen.

... zum den anderen Beiträgen

Übrigens kann der U-Boot auch Squashfs booten, allerdins muss das wieder an Version 2.0 angepasst werden.

Und eine Update-Funktion ohne CRC ist meiner Meinung nach tödlich, man bedenke das es ~ 98% der User sind die sich nicht so tief mit der Materie auskennen und was würde passieren wenn es irgendwo eine update.squash geben würde wo nur Schrott drin ist und die box hinterher " Kein System" schreit..

Riker

[krombacher]

Ich hab jetzt mal den Kernel einmal mit CONFIG_SQUASHFS=y un einmal mit n kompiliert. Irgendwie ändert sich dadurch die Größe merkwürdigerweise nicht.
Da der Patch aber nur 76kb groß ist, glaube ich nicht, dass der Vorteil durch die bessere Komprimierung durch den größeren Kernel zunichte gemacht wird.
Ist es das, worauf Du hinaus willst??? Irgendwie bin ich jetzt verwirrt. Vielleicht hilft ein bier

[JtG-Riker]

Funktioniert squashfs 2.0 nun oder nicht?

Also bei mir läuft's seit gestern problemlos. Und auf http://squashfs.sourceforge.net/ steht auch nix davon, dass das unstable oder experimentell ist. Und überstürzen müsst Ihr ja auch nichts. Ihr könnt es doch einfach mal ausprobieren. Ist ja nur ein anderer Kernelpatch und mksquashfs neu kompilieren. Und das image wird tatsächlich kleiner. Bei mir 200kb...
Wenn das dann in den Yadi Images läuft, kann's vielleicht auch offiziell im cvs übernommen werden?!?
Und was ist denn jetzt mit u-boot? Sat_Man schreibt, dass u-boot jetzt squashfs booten kann, aber essu bestätigt, dass für den Kernel jffs2 verwendet wird... Also geht squashfs doch immer noch nicht???

Also Fakt ist das u-boot 1.1.1 Squashfs 1.3 booten kann. Im Yadi ist es noch nicht drin weil das zu der Zeit wo Yadi rauskam noch nicht ging, und sich die User dann auch wieder umdenken müssen, da ja auch 2.0 schon angekündigt war denke ich das wär nicht sehr gut 2x in kurzer Zeit die Partitionen des Images zu ändern da nix mehr kompatibel ist. Aber das kann essu sicher besser beantworten.

[kroki]

Also Fakt ist das u-boot 1.1.1 Squashfs 1.3 booten kann. Im Yadi ist es noch nicht drin weil das zu der Zeit wo Yadi rauskam noch nicht ging, und sich die User dann auch wieder umdenken müssen, da ja auch 2.0 schon angekündigt war denke ich das wär nicht sehr gut 2x in kurzer Zeit die Partitionen des Images zu ändern da nix mehr kompatibel ist. Aber das kann essu sicher besser beantworten.

Also ich erstelle mein Image mit einer squashfs- und einer jffs2-Partition.
Der Kernel liegt im squashfs. U-Boot 1.1.1 bootet vom squashfs, und die Update-Funktion funktioniert auch einwandfrei.....

Gruß Kroki

[essu]

Also ich erstelle mein Image mit einer squashfs- und einer jffs2-Partition.
Der Kernel liegt im squashfs. U-Boot 1.1.1 bootet vom squashfs, und die Update-Funktion funktioniert auch einwandfrei...

SquashFS 2.0 ?
Update-Funktion: die ist ja in den Yadi_images nur deaktiviert, weil es keinen Check gibt, funktionieren würde sie grundsätzlich schon.

Ich hab jetzt mal eine Woche lang SquashFS 2.0 getestet und mein Eindruck ist, dass es stabil und (zumindest subjektiv) schnell ist. Wie sind denn die Chancen das und Kernel 2.4.26 (nach einer Testphase) zum CVS-Standard zu machen, sieht da irgend jemand Nachteile?

[kroki]

Sorry hab ich glatt vergessen: squashfs 1.3r3

Ich hab mir das squashfs 2.0 auch schon mal angesehen, nur damit ich es sinnvoll einsetzten kann müsste auch der U-Boot mit V2.0 arbeiten, das wollte ich mal ausprobieren, bin aber noch nicht dazu gekommen...#

Gruß Kroki

[mogway]

U-Boot mit V2.0

Oder darf es gleich V6 sein...

Der Kernel 2.4.26/ SquashFS 2.0 läuft hier bei mir auch stabil. Eine Aufnahme des Kernels 2.4.26 ins CDK würde ich sehr begrüssen.

Gruss
mogway

[woglinde]

Hi mogway,

mach halt patche dann ists ganz schnell drin.

Gruss woglinde

[mogway]

mh halt patche dann ists ganz schnell drin.

So läuft es ja momentan.

Bin halt nur nicht so ein Freund von der vielen Patcherei

Gruss
mogway