Closed GoogleCodeExporter closed 9 years ago
It sounds like there is also a bug in the FMK scripts too, as this should never
happen. The extract script saves off the unsquashfs version (to include
compression type) that was used to extract the squashfs image, and this is used
by the rebuild script to re-build the image; the rebuild script never sees the
binwalk output. This is out of necessity, as on most versions of squashfs
(i.e., anything prior to squashfs 4.0) there is no way to reliably determine
which compression type was used (except for trial and error). Further, some
vendors swap the compression definitions in the squashfs headers (they report
gzip when they really used lzma and vice versa).
So if the scripts were able to extract the image, they should be able to
rebuild. Of course, I'm sure there's a bug in my code somewhere that's
preventing this... :\
Original comment by heffne...@gmail.com
on 10 Jun 2013 at 7:17
[deleted comment]
I see what you mean now with unsquashfs-all! Fixing all this up now.
Original comment by jeremy.collake@gmail.com
on 11 Jun 2013 at 7:47
It appears for squashFS versions 4.x, where the compression type can be
specified via -comp to mksquashfs, the failure to save the compression type in
FS_TYPE causes it to use gzip instead of lzma. Older squashfs versions aren't
affected, as unsquashfs-all properly detects the squashfs lzma variant.
Further, the -comp switch isn't being properly applied to all mksquashfs
versions.
All fixing in the next commit (trying to make a single one this time ;p)
Original comment by jeremy.collake@gmail.com
on 11 Jun 2013 at 8:02
I mean FS_COMPRESSION not FS_TYPE .. all fixed now.
Original comment by jeremy.collake@gmail.com
on 11 Jun 2013 at 8:07
This issue was closed by revision d20640c26dbf.
Original comment by jeremy.collake@gmail.com
on 11 Jun 2013 at 8:08
Original issue reported on code.google.com by
jeremy.collake@gmail.com
on 10 Jun 2013 at 3:35