FB 6660: Unpacking filesystem image failed (Data queue size is too large)

[TSRBerry]

This is similar to #747, but this time the issue happens while building an image for the FB 6660.

I tried to get more information by increasing the verbosity in menuconfig, but in the end I got the same output.
I also tried to build the image using the latest tag ng23110 instead of the latest commit 22ea9dae3, but still got the same result.
Since the image signature is valid I don't think there is any file corruption, but I still tried to use a manually downloaded image file as well, which unsurprisingly also failed.

Build error output:

STEP 1: UNPACK
source firmware file: dl/fw/FRITZ.Box_6660_Cable-07.57.image
checking signature: valid
unpacking firmware image
unpacking uimg file
unpacking filesystem image
    FATAL ERROR:Data queue size is too large
    Filesystem on build/original/firmware/var/remote/var/tmp/x86/filesystem.image is xz compressed (4:0)
ERROR: modunsqfs: Error in build/original/firmware/var/remote/var/tmp/x86/filesystem.image
FINISHED

I'm not sure if this helps at all, but here are the filesystem superblock information that unsquashfs was able to find:

./tools/unsquashfs4-avm-le -s dl/fw/FRITZ.Box_6660_Cable-07.57.image.mod/original/firmware/var/remote/var/tmp/x86/filesystem.image
Found a valid little endian SQUASHFS 4:0 superblock on dl/fw/FRITZ.Box_6660_Cable-07.57.image.mod/original/firmware/var/remote/var/tmp/x86/filesystem.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 32227.54 Kbytes (31.47 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 461
Number of inodes 6016
Number of ids 1

Is there anything I can do to provide more information?

[pfichtner]

I guess it's the NOFILE ("max number of open files") limit of ulimit on your machine.

pfichtner/pfichtner-freetz#37 for reference (there the machine's NOFILE limit was ok but ot that for containers)

[TSRBerry]

Ohhh that's good guess, I'll try that! I was using your image as well after my own docker image failed to build it.

[pfichtner]

Should it work on the host but fail inside the container please follow https://github.com/pfichtner/pfichtner-freetz#known-problems

[TSRBerry]

Yup, worked without issues! I also saw that section when I tried your image for the first time, but somehow didn't think I had the same issue as the described one. 😅
Thank you very much for the quick help! :D