Which tool should I use for dumping squashfs volume? On Wed, Sep 11, 2019 at 2:55 AM David Oberhollenzer <david.oberhollenzer@xxxxxxxxxxxxx> wrote: > > On 9/10/19 9:31 PM, Richard Weinberger wrote: > > On Tue, Sep 10, 2019 at 3:11 PM Boris Stein <boris.stein@xxxxxxxxx> wrote: > > > > [...] > > > >> [ 9.006327] SQUASHFS error: zlib decompression failed, data probably corrupt > >> [ 9.006359] SQUASHFS error: squashfs_read_data failed to read block 0x785a5a > > > > usually squashfs has a blocksize of 1k or 4k. So block 0x785a5a is out > > of bounds. > > > > SquashFS has a device block size that is either 1k or 4k that is only relevant > for I/O transfers. The actual block size is between 4k to 1M (defaults to 128k). > The data blocks also have no headers or checksums. > > Meta data (inodes, directory entries, tables) is chopped in 8k chunks and stored > possibly compressed with a 2 byte header. > > Once compressed, blocks can have any size and there is absolutely no requirement > for alignment. Inodes (or in this case the fragment table) can literally point > just anywhere between the super block and the inode table. > > >> [ 9.012677] SQUASHFS error: Unable to read fragment cache entry [785a5a] > >> [ 9.019470] SQUASHFS error: Unable to read page, block 785a5a, size d6b4 > >> [ 9.026242] SQUASHFS error: Unable to read fragment cache entry [785a5a] > >> [ 9.032876] SQUASHFS error: Unable to read page, block 785a5a, size d6b4 > >> [ 9.039529] SQUASHFS error: Unable to read fragment cache entry [785a5a] > >> [ 9.046225] SQUASHFS error: Unable to read page, block 785a5a, size d6b4 > >> [ 9.052910] SQUASHFS error: Unable to read fragment cache entry [785a5a] > >> [ 9.059573] SQUASHFS error: Unable to read page, block 785a5a, size d6b4 > >> [ 9.066281] SQUASHFS error: Unable to read fragment cache entry [785a5a] > >> [ 9.072954] SQUASHFS error: Unable to read page, block 785a5a, size d6b4 > >> > >> > > SquashFS tries to read a fragment block located some ~7.5 MiB after the > super block (0x785a5a) with a compressed size of 54964 bytes (0xd6b4). > For a ~41 MiB SquashFS image this sounds plausible. > > Uncompressing fails, so the location that the fragment table points to does > not contain a valid zlib stream. > > > Interestingly, the inode, directory and fragment tables seem to be at least > partially readable. Accessing the root inode and walking through the tree > seems to work, since there are no other SquashFS error messages. > > *Assuming* that it is not the data that is broken, *if* there are no xattrs > and NFS export tables, the fragment table is pretty much at the very end. > Maybe the filesystem is partially chopped off at the end? > > > Have you tried dumping the SquashFS image from the UBI volume and extracting it? > (E.g. using unsquashfs, rdsquashfs or sqfs2tar which generate more useful error > messages about what actually broke) > > > Regards, > > David ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/