Re: cannot ubiupdatevol squashfs image

[David Oberhollenzer <david.oberhollenzer@xxxxxxxxxxxxx>]

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/