Re: cannot ubiupdatevol squashfs image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux