Petit problème :

############# Erreur #############
Traceback (most recent call last):
  File "./krnfbx", line 62, in ?
    open(sys.argv[3],"w").write(pylzma.decompress_compat(open(sys.argv[2]).read()[12:],hexval))
AttributeError: 'module' object has no attribute 'decompress_compat'
##################################

Je ne vois pas le problème :  l'attribut  'decompress_compat' existe bien ??

Ok, mais en fait je n'ai pas posé la bonne question smile
Ce que je veux dire : ayant dumpé la flash avec HairyDairyMaid, j'ai trois binaires correspondant au cfe, au kernel, et à la nvram.
C'est tout ce que j'ai.
Ce que je cherche : le root fs
Est-ce que je vais le trouver là dedans, ou bien est-il ailleurs ?

La page du Wiki pour ça n'a pas encore été écrite :.

smile autant pour moi

CFE, c'est binaire. Kernel c'est un kernel compressé en LZMA. Il n'y a que le romdisk qui est en cramfs.

le romdisk ?

Je suis également intéressé smile

Merci, c'est beaucoup plus clair comme ça wink

J'ai déjà splitté le contenu de la rom en différentes parties (cfe, kernel, nvram) avec HairyDairyMaid.
Le problème, c'est que je n'arrive pas à monter ces images (que je suppose de type cramfs ? ).

PS : j'ai un "Vous n'avez pas accès en écriture à cette page !" quand j'essaie d'acceder à "SplitRawDump".

Savi ->  est-ce qu'il y aurait moyen d'avoir quelques petits commentaires sur le script ?
Disons que ça n'est pas hyper lisible wink

Et la V3 ?

Après avoir dumpé la flash, je ne parviens pas à

1. monter l'image
`mount -o loop -t cramfs whole_flash.bin /mnt/loop
`
mount: wrong fs type, bad option, bad superblock on /dev/loop/0 [...]

un ` dmesg | tail` me donne
cramfs:wrong magic

2. extraire le contenu de l'image
`cramfsck -x rom whole_flash.bin`

cramfsck: superblock magic not found

3. J'ai pensé à un swap (Big Endian -> Little Endian)
`cramfsswap whole_flash.bin whole_flash.img`

cramfs magic not detected


Quelqu'un a une idée ?


Dans Documentation/filesystems/cramfs.txt (Doc kernel Linux)

[...]
Currently, cramfs must be written and read with architectures of the
same endianness, and can be read only by kernels with PAGE_CACHE_SIZE
== 4096.  At least the latter of these is a bug, but it hasn't been
decided what the best fix is.  For the moment if you have larger pages
you can just change the #define in mkcramfs.c, so long as you don't
mind the filesystem becoming unreadable to future kernels.
[...]

peut être faut-il adapter le PAGE_CACHE_SIZE ? (mais comment ?)