Check a Minix Filesystem Safely with fsck.minix

You will finish with a controlled way to check a Minix filesystem, understand the result, and decide whether an interactive repair is justified. The examples use the installed fsck.minix from util-linux 2.41.3. The local manual page is generated from util-linux 2.39.3, so the installed command and its help output are the authority for this machine.

Allow about fifteen minutes for a read-only check and longer for any repair. You need a shell, the target device or filesystem image, and enough privilege to read it. Repairing a real block device normally requires root, for example through sudo. Do not use this command on a mounted filesystem. A check can race with kernel writes and damage an otherwise healthy filesystem.

1. Identify the exact device

Use a device path, not the directory where a filesystem happens to be mounted. If you are working on a server, record the device and mount state before doing anything that can change it:

$ findmnt --source /dev/EXAMPLE_DEVICE
$ lsblk -o NAME,PATH,FSTYPE,SIZE,MOUNTPOINTS /dev/EXAMPLE_DEVICE

Replace /dev/EXAMPLE_DEVICE with the real Minix device, such as a partition or a loop-backed image. The output should identify the expected filesystem and show no active mount point. An empty findmnt result is useful: it means that command found no matching mounted source, although you should still check the device path and any other way it could be in use.

Checkpoint: stop if the device is mounted, if the filesystem type is not Minix, or if you cannot explain which data it contains. Unmounting a live filesystem is a service-disrupting action. If you choose to do it, use the normal service and maintenance procedure for that host, then verify again with findmnt. Do not force an unmount just to make fsck.minix run.

2. Confirm the installed command

This is an ordinary, read-only check and does not need elevated privileges:

$ command -v fsck.minix
/usr/sbin/fsck.minix
$ fsck.minix --version
fsck.minix from util-linux 2.41.3
$ fsck.minix --help

Check that the path and version are the ones you expect. The useful syntax is one device after the options:

fsck.minix [options] DEVICE

Do not append a mount point, a directory, or an option copied from another filesystem checker. fsck.minix checks Linux Minix filesystems; a non-Minix device normally produces a bad magic number diagnostic.

3. Run a read-only check first

Start without -r or -a. The command will inspect the filesystem and will not ask to repair it:

$ fsck.minix -v /dev/EXAMPLE_DEVICE
$ printf 'fsck.minix status: %s\n' "$?"
fsck.minix status: 0

A clean check can be quiet even with -v. The exit status is more useful than a guessed interpretation of the screen output. Status 0 means no errors. Status 3 means errors were corrected, status 4 means errors remain uncorrected, status 7 combines those two filesystem results, status 8 is an operational error, and status 16 is a usage or syntax error.

The command can return a non-zero status for a reason that needs investigation rather than repair. Save the complete diagnostic and rerun the identity checks if you see an operational error. A missing device commonly leads to an inability to read the superblock; a device with another filesystem commonly reports a bad magic number.

4. Inspect the superblock without repairing

Use -s when you need the filesystem's superblock information:

$ fsck.minix -s /dev/EXAMPLE_DEVICE

Output varies with the Minix version and the filesystem contents. This option is for inspection. It does not turn a non-Minix device into a Minix filesystem and does not fix a damaged one. Keep the output with your incident or recovery notes if you are investigating a failing disk image.

-l lists filenames and -m enables MINIX-style "mode not cleared" warnings. They are diagnostic options, not substitutes for an unmounted device or a backup. Add -f to force a check when the filesystem is marked valid, but only after you have confirmed that the device is quiescent.

5. Choose repair mode deliberately

Repair changes filesystem metadata. Treat it as a potentially destructive operation and make sure you have a usable backup or a disposable image first. Stop any service using the data, unmount the filesystem, and verify the device path again before proceeding. These checks usually need elevated privileges:

$ sudo fsck.minix -r /dev/EXAMPLE_DEVICE

-r performs interactive repairs. Read each question and use the default only when you understand what it will change. Capture the final exit status:

$ printf 'fsck.minix status: %s\n' "$?"
fsck.minix status: 0

Do not use -a as a convenient shortcut on a valuable filesystem. It implies repair and answers every question with the default. The manual warns that this can be extremely dangerous when damage is extensive. Automatic repair is appropriate only when your recovery plan explicitly accepts those defaults and you have tested it against a copy.

If the command prints FILE SYSTEM HAS BEEN CHANGED, it has repaired the filesystem and synchronises the changes before exiting. The manual says that a reboot is not normally needed after a check, but its exit-status description calls for a reboot if errors were corrected on a mounted filesystem. That apparent edge case is another reason not to check mounted data: follow the operating system's recovery procedure rather than trying to keep using a changed, mounted filesystem.

6. Diagnose the common traps

Bad magic number in super-block: check the device name and filesystem type. You may have selected the wrong partition, an encrypted container, or a filesystem that is not Minix. Do not respond by adding -a.

Unable to read superblock: confirm that the path exists and that the device is accessible. This can be a missing image, a permissions problem, or failing storage. Check with:

$ ls -l /dev/EXAMPLE_DEVICE
$ test -r /dev/EXAMPLE_DEVICE && echo 'device is readable'

The command reports a mounted filesystem: stop. Find the process and the owning service through your normal operations tooling, arrange downtime, unmount cleanly, and verify with findmnt. Never rely on a quiet check as proof that a mounted device was safe.

The status is 4 or 7: repairs were not complete. Preserve the output, avoid repeatedly running automatic repair, and move to a tested recovery or filesystem-specialist procedure. Repeated writes to a failing device can reduce the chance of recovering data.