squashfs-tools is where the read-only filesystem image behind a Linux install actually comes from

The upstream source behind the Squashfs format

This is the official Squashfs-tools repository, and its purpose is narrower than the name suggests. It does not contain a Linux distribution, a boot loader or an installer. It contains the C sources for the tools that create and extract Squashfs filesystems, the family of programs around mksquashfs, plus the documentation and the change log. Squashfs is the read-only compressed filesystem format that Linux distribution images are built from, so almost every route to a bootable media image passes through code in this repository. The practical question the repository answers for you is narrow and practical: which version of the tools am I running, and where did they come from. The topic list on the repository names the format directly, with squashfs, squashfs-image, mkfs, mksquashfs, lzo, zstd, tar and archiving.

Documentation is versioned, and 4.7.6 is already open

The Documentation directory is organised by version, and it is split into subdirectories for versions 4.5 through 4.7.6. The distinction the repository makes is explicit: the latest released version is 4.7.5, and the development version will become 4.7.6. There is also a directory holding prebuilt manpages for the latest development version. That means the docs for the version you are about to build are already in the tree, including one for a version that has not shipped yet. This is unusual and useful. A reader trying to learn the tool from the current release notes would miss the newest options, and a reader following a 4.5-era tutorial would hit commands that have since been renamed. The pattern is to read the documentation directory that matches the version, not the newest one on the main branch. The top level also carries INSTALL, README and USAGE files whose stated purpose is to point you at the file for your version.

Building means make inside squashfs-tools/

The source lives in a single directory, squashfs-tools/, and the documented build is short. You enter that directory and type make to build, and sudo make install to install. There is no configure step and no autoconf run described here:

make

and the same Makefile then installs the tools into the install PATH you configured, which the README describes as the sudo make install step. That simplicity is a direct consequence of how the project is configured. The Makefile is the configuration surface, and the README names exactly what it controls: the compression algorithms built, other defaults, the install PATH, XATTR support, and the number of parallel reader threads. So the question that a configure script would normally ask you is asked of a text file instead. If you need a different compression algorithm, a different install location, extended attribute support turned on or off, or a different number of reader threads, you change the Makefile before you build rather than passing flags to a build step.

Where the packaged version is usually the better answer

The repository itself tells you when not to build it. The README states that the latest 4.7.5 release may have already been packaged for your distribution, and points to a packaging status badge that reads from repology. That is a real constraint on the value of compiling from source. If your distribution ships 4.7.5, then building 4.7.5 yourself buys you a locally managed copy of something you can install from your package manager, and you take on the job of tracking security updates yourself. The case for building is therefore specific: you need a version your distribution does not package, you need a configuration the packaged build does not have, such as a different algorithm set or XATTR behaviour, or you need to apply a change before it is packaged. For everybody else, the packaged build wins on update handling, and the repository is telling you so.

What the top-level files are actually for

The top level of the repository is mostly a table of contents for a project with a long history, and the file list explains why each entry exists. ACKNOWLEDGEMENTS holds historical acknowledgements, and the note says that file has mostly been replaced by the GitHub issues tracker. CHANGES is a reverse chronological list of changes from the latest release to the earliest, and CHANGES.md is the same content in markdown form. COPYING is the GNU general public licence file. CONTRIBUTING.md explains how to ask for features and how to do pull requests. SECURITY.md is where to report security issues, which matters for a tool that parses untrusted filesystem images. The reverse chronological CHANGES file is the file to read before an upgrade, since it tells you what changed between the version you have and the version you are installing.

Where the real risk sits in a Squashfs toolchain

There is a specific failure mode to think about here, and it is not a build failure. Squashfs tools read compressed images that may have been downloaded from elsewhere, and the format is a filesystem format, which means the reader has to handle adversarial input correctly. A decompression bug in an image reader is a security bug, and the reason the repository ships SECURITY.md is that reporters need a channel for it. The same applies to the other end: mksquashfs takes a directory tree and compresses it, so a corrupt input tree or a broken build produces an image that other people's tools will later try to read. A second limitation is the version coupling. The tools write and read a specific format version, and the documentation is kept per release for that reason. Building 4.7.6 development sources while your distribution's kernel expects 4.7.5 behaviour is a mismatch you own.

Licence and the rhythm of releases

The licence field on the repository says GPL-2.0, and COPYING is the GNU general public licence file. For a set of command line utilities that ship inside distribution images this matters in the usual way: the tools are distributed as part of a larger work, and the file exists in the tree rather than being linked from elsewhere. The release history shows a steady but not frantic cadence, with 4.7.5 on 2026-03-01, 4.7.4 on 2025-11-09 and 4.7.3 on 2025-11-05. The last push was on 2026-08-22 and the repository is not archived, so work continues between releases. If you track this project, the two signals to watch are the CHANGES file and the Documentation directories, because a new version brings both a new set of options and a new set of files to read.

Editorial conclusion

squashfs-tools suits a builder who needs a specific Squashfs version, a specific set of compression algorithms, or a bug fix newer than the packaged one, and the per version Documentation directory is what makes that possible without archaeology. It does not suit an ordinary user who only needs to mount or create an image, since the release notes say the latest 4.7.5 may already be packaged for your distribution, and building from source replaces a working package with a self managed toolchain. Before you compile, read Documentation/4.7.5/INSTALL.md for the dependency list, then check the Makefile in squashfs-tools/ for the algorithms and XATTR support you need, because those defaults are decided there rather than by a configure step.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. plougher/squashfs-tools on GitHub
4. README
5. Releases