Ursache für 'Kein System'

[e46ti]

@gurgle,

ist nicht böse gemeint, aber diese images sind non public.

e46ti

[e46ti]

So, habe mich jetzt auch mal selber daran gemacht, denn Fehler beim kernel loading und der verkleinerten squashfs block_size einzugrenzen:

Code: Alles auswählen

### FS (squashfs) loading 'vmlinuz' to 0x100000

compressed block @ 0x646a43, compressed size 716, offset 2, buffer size 33073832
compressed block @ 0x646a43, uncompressed size 864

compressed block @ 0x644d20, compressed size 2388, offset 2, buffer size 33073944
compressed block @ 0x644d20, uncompressed size 7683

compressed block @ 0x645676, compressed size 5067, offset 2, buffer size 33073592
compressed block @ 0x645676, uncompressed size 8126

inode @ 644d20:1d90

compressed block @ 0x644d20, compressed size 2388, offset 2, buffer size 33073944
compressed block @ 0x644d20, uncompressed size 7683

regular file, size 623092, blocks 19
frag_bytes 500, start_block 0x5a8b3a

reading block 0
compressed block @ 0x5a8b3a, compressed size 32752, offset 0, buffer size 33073944
compressed block @ 0x5a8b3a, uncompressed size 32768

reading block 1
reading block 2
reading block 3
reading block 4
reading block 5
reading block 6
reading block 7
reading block 8
reading block 9
reading block 10
reading block 11
reading block 12
reading block 13
reading block 14
reading block 15

reading block 16
compressed block @ 0x628b2a, compressed size 32759, offset 0, buffer size 33073944
compressed block @ 0x628b2a, uncompressed size 32768

reading block 17
compressed block @ 0x630b21, compressed size 32627, offset 0, buffer size 33073944
compressed block @ 0x630b21, uncompressed size 32768

reading block 18
compressed block @ 0x638a94, compressed size 32747, offset 0, buffer size 33073944
compressed block @ 0x638a94, uncompressed size 32768

500 bytes in fragment 107, offset 24303

fragment 107, start_block=0x640a7f, size=13725
compressed block @ 0x640a7f, compressed size 13725, offset 24303, buffer size 33073944
compressed block @ 0x640a7f, uncompressed size 0

SQUASHFS error: zlib::uncompress failed

### FS load complete: 622592 bytes loaded to 0x100000

Der Fehler tritt bei dem Versuch auf, die restlichen 500 bytes, die sich in einem fragment block befinden, zu decomprimieren. Mit einer block_size = 65536 sieht das ganze so aus:

Code: Alles auswählen

### FS (squashfs) loading 'vmlinuz' to 0x100000

compressed block @ 0x62ed28, compressed size 558, offset 2, buffer size 33073832
compressed block @ 0x62ed28, uncompressed size 648

compressed block @ 0x62d0f4, compressed size 2177, offset 2, buffer size 33073944
compressed block @ 0x62d0f4, uncompressed size 6883

compressed block @ 0x62d977, compressed size 5039, offset 2, buffer size 33073592
compressed block @ 0x62d977, uncompressed size 8102

inode @ 62d0f4:1a98

compressed block @ 0x62d0f4, compressed size 2177, offset 2, buffer size 33073944
compressed block @ 0x62d0f4, uncompressed size 6883

regular file, size 623092, blocks 9
frag_bytes 33268, start_block 0x58c62f

reading block 0
compressed block @ 0x58c62f, compressed size 65530, offset 0, buffer size 33073944
compressed block @ 0x58c62f, uncompressed size 65536

reading block 1
reading block 2
reading block 3
reading block 4
reading block 5
reading block 6
reading block 7

reading block 8
ompressed block @ 0x60c629, compressed size 65381, offset 0, buffer size 33073944
compressed block @ 0x60c629, uncompressed size 65536

33268 bytes in fragment 80, offset 0

fragment 80, start_block=0x6243a1, size=33238
compressed block @ 0x6243a1, compressed size 33238, offset 0, buffer size 33073944
compressed block @ 0x6243a1, uncompressed size 33268

### FS load complete: 623092 bytes loaded to 0x100000

Auch hier gibt es am Ende einen fragment block. Auffällig ist hier aber, daß die Daten im fragment block keinen offset haben.

Hat irgend jemand eine Idee zu diesem Thema?

e46ti

[ALexH]

@e46ti:
Falls es hilft: Ich habe vor ein paar Monaten etwas am Partitions-Layout herumgespielt (uboot vorne oder uboot hinten) und folgendes feststellen können: War uboot vorne und die root-Partition hat zu "Kein System" geführt, so hat die selbe root-Partition booten können, als uboot hinten war.

[alexW]

Jein, alexW hat ein Programm geschrieben, welches genauso wie das von derget, dass cramfs oder squashfs auf bad magics untersucht.

Falsch. Mein Tool (welches lange vor Dergets Version geschrieben wurde) erkennt 100%ig alle Faelle, die ein "Kein System" verursachen und kann diese auch beheben!
Es ist also nicht nur eine Erkennung.
Ob cramfs, squashfs, oder egal was, ist allerdings richtig.

[essu]

Na toll, da werden einem ja richtig die Augen feucht bei soviel Hilfsbereitschaft. Ob dieser thread auch so lang wird wie der zum HDD-Einbau?

[Sat_Man]

Jein, alexW hat ein Programm geschrieben, welches genauso wie das von derget, dass cramfs oder squashfs auf bad magics untersucht.

Falsch. Mein Tool (welches lange vor Dergets Version geschrieben wurde) erkennt 100%ig alle Faelle, die ein "Kein System" verursachen und kann diese auch beheben!
Es ist also nicht nur eine Erkennung.
Ob cramfs, squashfs, oder egal was, ist allerdings richtig.

Wenn du unter beheben verstehst, dass das cramfs, squashfs automatisch von deinem Programm so geändert wird, dass man es anschließend auf die Box flashen kann ohne eine "kein System" Meldung zu bekommen, dann wäre das neu.

Die Version von der du mir damals erzählst hast konnte die Fehler nur erkennen, aber nicht automatisch beheben.

[e46ti]

@ALexH

dieses Phänomen habe ich auch schon beobachtet. Es hilft manchmal auch den Kernel in eine extra Partition (cramfs/squashfs) zu packen. Aber diese Maßnahmen sind halt nur dazu geeignet, bei dem jeweiligen image zu funktionieren. Macht man später einmal Änderungen kann es durchaus sein, daß es wieder nicht geht.

@alexW
Solch ein tool ist eine sehr interessante Fragestellung, für die es sich lohnt Zeit zu investieren..

@all
Bis dahin werde ich mir auf eine andere Art behelfen:

Kernel --> squashfs mit block_size=65536 oder cramfs --> kann u-boot richtig verarbeiten

Das restliche root --> squashfs mit block_size=32768, nur umzu testen ob es unter diesen Bedingungen auch zu dem Fehler kommt.

@essu
Die Unterstützung hier ist prächtig , es geht ja auch nicht um so etwas wie boot net failed!

e46ti

[kroki]

von AlexW:

Falsch. Mein Tool (welches lange vor Dergets Version geschrieben wurde) erkennt 100%ig alle Faelle, die ein "Kein System" verursachen und kann diese auch beheben!
Es ist also nicht nur eine Erkennung.
Ob cramfs, squashfs, oder egal was, ist allerdings richtig.

@AlexW
Wenn du dieses Tool geschrieben hast, dann weisst du doch sicher auch was zu der Meldung "kein System" führt. Lass uns doch nicht im Dunkeln tappen ......

@e46ti
Hast du im U-Boot die Blockgröße angepasst (squashfs_fs.h)?

Gruß Kroki

[e46ti]

Hallo Kroki,

danke für den Hinweis. Daran habe ich auch schon mal gedacht. Ich habe die beiden Einträge dort so verstanden, daß einmal eine default block_size definiert wird und eine obere Grenze. Die aktuell benutzte block_size wird aber aus dem header des squashfs images selbst ausgelesen:

Code: Alles auswählen

SquashFS version: 2.1 
Files: 675 
Bytes_used: 6581529 
Block_size: 32768 ----------> schau hier!!!
Inodes are compressed 
Data is compressed 
Fragments are compressed 
Check data is not present in the filesystem 
Fragments are present in the filesystem 
Always_use_fragments option is specified 
Duplicates are removed 
Filesystem size 6581529 bytes 
Number of fragments 108 
Number of inodes 675 
Number of uids 1 
Number of gids 0

Dafür spricht auch, daß sich mit verschiedenen bock_sizes erstellte squashfs images auf dem PC problemlos mounten lassen ohne das der squashfs kernel patch jeweils angepaßt werden muß.

e46ti

[kroki]

@e46ti

Das ist schon richtig, für das laden des Kernels ist doch aber der U-Boot zuständig, und hier ist das squashfs nur soweit implementiert, das dieser den Kernel booten kann. Ich kann mir schon vorstellen, das man hier einfach von einer festen Blockgröße ausgeht.

/* default size of data blocks */
#define SQUASHFS_FILE_SIZE 65536 <---
#define SQUASHFS_FILE_LOG 16

Das sieht mir doch so aus. als wenn hier die Blockgröße festgelegt ist,oder ?

Kroki

[e46ti]

@kroki

Ich kann mir schon vorstellen, das man hier einfach von einer festen Blockgröße ausgeht.

Nein, in den u-boot squashfs sourcen gibt es eine routine zur Abfrage der aktuell verwendeten squashfs parameter. Danach wird u.a. die block_size aus dem image header richtig eingelesen - s. mein letztes posting -.

Das es bei mir mit dem kernel decomprimieren nicht klappt, liegt an etwas anderem. Ich bin aber noch nicht dazu gekommen, weiter zu testen...

e46ti

[kroki]

@e46ti

So ich bin auch mal ein bischen auf due Suche gegangen.....

In der mkflfs.c stehen die Superblocks für ddas FLFS drinnen.

flfs Superblock : F0 A4 03 01

Diese habe ich mal in den Original-Images gesucht und gefunden.

Jetzt ist nur die Frage, wie der BR-Loader den Speicher scannt. Ich denke mal das er nicht das ganze Flash durchsuchen kann, dafür geht es zu schnell. Bei allen original-images die ich mal durchsucht habe liegt das FLFS immer an einer 128KByte-Grenze und ziehmlich weit hinten .....

Hast du noch images die nicht funzen (wenn man mal eins braucht kommt immer Loading kernel ), dann such mal nach den Superblockdaten, vielleicht klappt es ja.....

Gruß KROKI

[gurgel]

meine vermutuing ist, dass der das sector-weise scannt.

[e46ti]

@all

So, jetzt klappt das auch mit dem kernel bei einer squashfs block_size = 32768. Der Fehler war, daß sich der offset Wert für einen fragment block nicht auf die compressed size bezieht sondern auf die uncompressed size.

Code: Alles auswählen

### FS (squashfs) loading 'vmlinuz' to 0x100000

compressed block @ 0xaeb81, compressed size 117, offset 2, buffer size 33172192
compressed block @ 0xaeb81, uncompressed size 182

compressed block @ 0xaeb81, compressed size 117, offset 2, buffer size 33172192
compressed block @ 0xaeb81, uncompressed size 182

regular file, size 623092, blocks 19, start_block 0x162f7

reading block 0
compressed block @ 0x162f7, compressed size 32752, offset 0, buffer size 33172192
compressed block @ 0x162f7, uncompressed size 32768
reading block 1
reading block 2
reading block 3
reading block 4
reading block 5
reading block 6
reading block 7
reading block 8
reading block 9
reading block 10
reading block 11
reading block 12
reading block 13
reading block 14
reading block 15
reading block 16
compressed block @ 0x962e7, compressed size 32759, offset 0, buffer size 33172192
compressed block @ 0x962e7, uncompressed size 32768
reading block 17
compressed block @ 0x9e2de, compressed size 32627, offset 0, buffer size 33172192
compressed block @ 0x9e2de, uncompressed size 32768
reading block 18
compressed block @ 0xa6251, compressed size 32747, offset 0, buffer size 33172192
compressed block @ 0xa6251, uncompressed size 32768

500 bytes in fragment 0, offset 3524

fragment 0, start_block=0xae23c, size=2373
compressed block @ 0xae23c, compressed size 2373, offset 0, buffer size 33172192
compressed block @ 0xae23c, uncompressed size 4024

### FS load complete: 623092 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:    623028 Bytes = 608.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Schön an Sache ist, daß die dafür notwendigen Änderungen an den squashfs sourcen dynamisch sind. Soll heißen, daß u-boot so auch für die block_size = 65536 zu verwenden ist

@gurgel
Das sehe ich auch so.

@Kroki
Verantwortlich für den Fehler scheinen mir bestimmte Ziffernfolgen an den 128 KB Grenzen zu sein. Mein nächstes Projekt wird jetzt sein, die squashfs sourcen so zu modifizieren, daß genau diese 128 Grenzen vom squashfs einfach nicht benutzt/ausgespart werden, mal sehen....

Fakt ist jedenfalls, das ein image welches mit einer squashfs block_size=65535 nicht läuft, mit der block_size=32768 ohne weitere Änderungen funktioniert

e46ti

[DieMade]

Einfach "Bereiche weglassen" halte ich für eine schlechte Lösung, Kernel und GUIs wachsen ständig und bei 8MB Flash kommt es auf jedes Byte an.

[e46ti]

Hm,

8.257.536 / 131072 * 16 = 1008 bytes

Wenn es wirklich das Problem löst, sollte der Verlust doch zu verschmerzen sein, oder???

Zumal man dann ja den kernel mit ins squashfs nimmt und diese readonly Partition bis auf 100% aufffüllen kann.

e46ti

[DieMade]

Der Kernel IST im squashfs...

[e46ti]

Ja, warum nicht. Geht prima...

[DieMade]

Zumal man dann ja den kernel mit ins squashfs nimmt

Ich bezog mich darauf - bei mir ist der Kernel schon lange im squashfs und nicht erst "dann"

[e46ti]

Achso...

[e46ti]

@all

Ich habe jetzt alle Tests abgeschlossen und danach stellt sich das Problem 'kein System ---> superblock not ok: invalid argument' folgendermaßen dar:

Der BM bootloader scanned direkt nach dem Einschalten der box den flash. Dabei werden gezielt alle Adressen abgefragt, die den 128 KB Sektorgrenzen entsprechen, also 0x1fff0 - 0x1ffff --> 16 bytes, 0x3fff0 - 0x3ffff --> 16 bytes usw. In dem BM Orginal image befinden sich an diesen Stellen Zeichenfolgen, die als Signatur interpretiert werden können, z.B:

00 01 00 01 00 77 00 40 FF 88 FF BF C3 FF C3 FF

Bei der Analyse dieser Zeichenfolgen kommt heraus, das die 77, 40, 88 und BF (d.h immer die Zeichen an diesen Stellen) verschlüsselt mit der jeweiligen sector_count korrelieren. C3 FF C3 FF ist wohl eine Kennung, die dem bootloader signalisiert das wieder eine relevante Stelle im Flash erreicht wurde.

Unter ungünstigen Umständen kann es nun passieren, daß in cramfs oder squashfs Partitionen ähnlich Zeichenfolgen an den 128 KB Grenzen auftreten, und den bootloader dadurch veranlassen zu reagieren ---> kein Sytem: invalid argument, z.B.:

BC 47 99 37 9E 6D E5 8D 0F 87 2D 45 5B 18 C3 CE

Mögliche Lösungsansätze:

- Das squashfs mit einer kleineren block_size erzeugen.

- Squashfs sourcen so anpassen, das die 128 KB Grenzen ausgespart werden

- Ideen anderer Interessierter??

- AlexW/Derget nach ihren tools fragen

- Sich mit dem status quo zufrieden geben


e46ti

[kroki]

@e46ti

Hi,
das hört sich ja schon sehr gut an.....
Für mich stellt sich da noch die Frage : Scannt der BR-Loader erstmal den kompletten Flash und entscheidet dann von wo er das FLFS lädt, oder nimmt er das erste was er findet ? Wenn er von 0 bis zum Ende scannt müsste er doch eigentlich das FLFS (wenns vorne liegt) zuerst finden.

Wenn der Loader mehrere FLFS-Partitionen irrtümlich findet, prüft er diese auf Gültigkeit ???

Was ist mit dem jffs2: hier könnte es doch auch sein, das mal diese Zeichenfolgen auftreten -> dann dürfte die Box doch auch nicht mehr booten !

Gruß Kroki

[e46ti]

@Kroki

Ich gehe davon aus, daß zunächst einmal der flash in 128 KB Schritten komplett gescanned wird. Dafür spricht, daß bei meinen Tests egal war wo u-boot steht, d.h. es kommt immer 'Kein System' wenn die o.g. Ziffernfolge an einer 128KB Grenze im squashfs/flash steht.

Bei einem jffs2 wird es genauso sein. Wurde ja hier auch schon beschrieben, daß es möglich ist, in einem jffs2 only gezielt diesen Fehler zu provozieren.

e46ti

[kroki]

@e46ti

Hab mal was interressantes : Hab ein Squashfs 2.1-Image was nicht funktioniert.
Image wird beim erstellen ja bis zur nächsten 4k-Grenze mit 0x00 aufgefüllt, wenn man die -nopad Option nicht angibt.

Hab jetz mal die Nullen hinten abgeschnitten, so daß hier im Flash nacher die 0xFF vom löschen stehen -> Image funktioniert jetzt !!!!

Das heisst doch : Es kann eigentlich nicht an den Bytes an den 128K-Grenzen liegen, denn diese haben sich nicht geändert !

Werde nochmal weiter mit anderen Größen testen ..............

Gruß Kroki

[e46ti]

@kroki

nimm ein squashfs was geht und ersetze darin mal die Zeichenfolge z.B an der Stelle 0x23fff0 -0x23ffff mit der o.g. Zeichenfolge:

BC 47 99 37 9E 6D E5 8D 0F 87 2D 45 5B 18 C3 CE

Danach wirst Du 'Kein System' bekommen.

Schick mir mal das squashfs was nicht geht, ich denke ich kann Dir dann die Stelle sagen, wo es klemmt. Bau dieses squashfs mal mit der kleineren block_size ---> sollte dann laufen (voher aber die squashfs sourcen für u-boot korrigieren!!).

e46ti