Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
mksquashfs sometimes fails with an error:
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on /tmp/test.sqs, block size 131072.
[===================================================================|] 1/1 100%Write failed because Bad file descriptor
FATAL ERROR:Failed to write to output filesystem
This error occurs occasionally, and was noticed by us in automated testing of the Singularity container runtime, which uses squashfs format images extensively, and therefore generates many squashfs images during tests. These tests fail only on RHEL8.
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux release 8.1 (Ootpa)
squashfs-tools-4.3-19.el8.x86_64
kernel 4.18.0-147.el8.x86_64
How reproducible:
On an EC2 RHEL8.1 instance (t3.small), this can be triggered consistently withing 10,000 iterations of `mkqsuashfs` on a single file. On a VM running under VirtualBox it has been consistently triggered within 1000 iterations.
Steps to Reproduce:
Create test script as test_mksquashfs.sh
#!/bin/sh
for i in $(seq 1 100000); do
rm -f /tmp/test.sqs
if ! mksquashfs $1 /tmp/test.sqs -noappend >/tmp/output 2>&1; then
echo "Failed - iteration $i"
cat /tmp/output
fi
done
Run script, creating squashfs from a file, e.g:
./test_mksquashfs.sh /etc/passwd
Actual results:
[ec2-user@ip-172-31-14-236 ~]$ ./test_mksquashfs.sh /etc/passwd
Failed - iteration 6190
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on /tmp/test.sqs, block size 131072.
[===================================================================|] 1/1 100%Write failed because Bad file descriptor
FATAL ERROR:Failed to write to output filesystem
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
compressed data, compressed metadata, compressed fragments, compressed xattrs
duplicates are removed
Filesystem size 0.82 Kbytes (0.00 Mbytes)
55.61% of uncompressed filesystem size (1.47 Kbytes)
Inode table size 51 bytes (0.05 Kbytes)
56.67% of uncompressed inode table size (90 bytes)
Directory table size 26 bytes (0.03 Kbytes)
92.86% of uncompressed directory table size (28 bytes)
Xattr table size 52 bytes (0.05 Kbytes)
100.00% of uncompressed xattr table size (52 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 1
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 2
Number of uids 2
Expected results:
Completes loop without any error.
Additional info:
Cannot be reproduced on an Ubuntu install running squashfs-tools 4.3
Does not reproduce using squashfs-tools 4.4 built from source
To follow up, the above referenced patch does appear to be a fix. I've built RPMs using a modified spec to apply this patch as the sole chance on top of squashfs-tools-4.3-19 and our tests which make extremely heavy use of squashfs now pass reliably:
https://github.com/sylabs/squashfs-tools-rpm-el8
(see finalized.patch)
https://github.com/sylabs/squashfs-tools-rpm-el8/releases/tag/v4.3-19.sylabs.1
^ Above linked here with the disclaimer that the packages have *only* been created for troubleshooting around this issue, and are not something we are maintaining.
(In reply to Tru Huynh from comment #4)
> thanks David.
>
> Red Hat squashfs maintener?
I'll roll this patch along with another change or two for the next squashfs-tools version for 8.4
This bug appears to be a dup of bug 1754815 and the patches in the build above (comment #13) fix it as well. Marking as dup.
*** This bug has been marked as a duplicate of bug 1754815 ***