Create a Minix filesystem safely with mkfs.minix

You will create a Linux Minix filesystem on a disposable image, select a Minix format when needed, and verify that the command completed. Allow about 10 minutes for the image example. Formatting a real partition takes less time, but the checking beforehand is the part you must not skip.

Before you start

mkfs.minix is part of util-linux. On this machine, mkfs.minix --version reports util-linux 2.41.3, while the installed util-linux package is reported by dpkg as 2.39.3-9ubuntu6.6. The command and its manpage can therefore describe slightly different builds. Run the version check on the host where you will work.

The device argument can be a block device or an image file. The examples use an image so that no partition is at risk. For a real device, you need enough privilege to open it, usually by running the formatting command with sudo. Ordinary inspection commands do not need elevated privileges.

Checkpoint 1: identify the target

1. Check the command version and help available on this host.

mkfs.minix --version
mkfs.minix --help

The long --version option cannot be combined with other options. The help output shows the short and long spellings supported by the installed binary, which is useful when a host has a different util-linux release.

Checkpoint 2: practise on an image

1. Create a 4 MiB image and format it with the default Minix version.

image=/tmp/minix-example.img
truncate -s 4M "$image"
mkfs.minix --lock "$image"

truncate creates the regular file used as the test device. The --lock option asks for an exclusive BSD lock while the command operates; with no mode it means yes. Locking is recommended because it reduces collisions with device-management tools. The default filesystem version is Minix version 1 and the default maximum filename length is 30 characters.

A successful run returns status 0 and prints values similar to these:

1376 inodes
4096 blocks
Firstdatazone=47 (47)
Zonesize=1024
Maxsize=268966912

The exact inode count and other values depend on the image size and chosen format. If the command returns 8, it encountered an operational error. Status 16 indicates a usage or syntax error. Check the target and the complete error text before trying again.

Checkpoint 3: choose the filesystem version

1. Format another image as Minix version 2 when the software using it requires that format.

image_v2=/tmp/minix-v2.img
truncate -s 4M "$image_v2"
mkfs.minix --lock -2 "$image_v2" 2048

The final argument requests 2,048 filesystem blocks. It exists for backwards compatibility; when omitted, the size is determined from the device. The local manpage documents counts greater than 10 and less than 65,536. Keep the count inside that documented range rather than relying on an older or newer binary to handle edge values consistently.

Use -3 for Minix version 3. Version 1 is the default, and -2 and -v are equivalent. Filename limits follow the format: versions 1 and 2 allow 14 or 30, while version 3 allows 60. For example:

image_v3=/tmp/minix-v3.img
truncate -s 4M "$image_v3"
mkfs.minix --lock -3 -n 60 "$image_v3"

Do not choose a version merely because it is the newest number. Minix filesystem support is often provided for compatibility with a specific kernel, tool or embedded system. Confirm the reader's requirements first.

Useful controls for unusual media

-c checks the target for bad blocks before creating the filesystem and prints the number found. This can take a while on real media. -l filename instead reads a supplied list, with one bad-block number per line, and reports how many entries it read. Treat both options as part of the formatting operation: the target is still written afterwards.

-i number sets the number of inodes. Only change it when you know the workload needs a different file count. Too few inodes can prevent new files even when free space remains; an arbitrary large value wastes filesystem space.

The default is no device lock. Prefer --lock for a device or image that could also be touched by another process. The LOCK_BLOCK_DEVICE environment variable can request locking with 1 or disable it with 0, but an explicit --lock option takes precedence. An unexpected lock failure is a reason to investigate competing processes, not to format a different device by guesswork.

Verify, then clean up the test

1. Check the exit status and inspect the image before using it elsewhere.

status=$?
printf 'mkfs.minix exit status: %s\n' "$status"
file /tmp/minix-example.img

Run the status capture immediately after mkfs.minix in your own shell. A zero status means the command reported no errors, not that the right device was selected. For a real filesystem, use the appropriate Minix checking tool before mounting or handing the device to another system, and keep the formatting output with your change record.

The image examples changed only files under /tmp. When you have finished testing, remove those named image files with your normal temporary-file cleanup process. If you formatted a real device by mistake, stop writing to it at once and use your organisation's backup or data-recovery procedure.

Done means

• The target path was independently identified and was not mounted or needed for another service.
• The selected Minix version and filename length match the consumer's requirements.
• mkfs.minix returned status 0 and its output was recorded.
• A lock was used where another process could access the device.
• Any bad-block check, inode choice and explicit block count were deliberate.