3.1. Partition and Directory Layout
Before filesystems are created or packages are installed, the target disk layout and the corresponding mount directories should be planned explicitly.
The book does not require a single fixed partition scheme. Readers may use a minimal layout or split the system across multiple filesystems, provided the final boot path exists and the mount layout remains coherent. What matters is that the choices are made deliberately before the build begins, because the directory structure created later will depend on them.
TODO: this book still needs a full partitioning walkthrough of its own. For now, readers should use one of these references for the actual disk setup steps before continuing:
Required Partitions
The only partition that is always mandatory is the root filesystem. It contains the target system itself and remains required regardless of how many other filesystems are introduced later.
On UEFI systems, the finished installation also needs access to an EFI System Partition so the bootloader and related files have somewhere to live. That does not mean the reader must create a fresh ESP specifically for this book. Reusing an existing ESP is fine if its size, mount policy, and ownership expectations are already understood.
Optional Layout Choices
The simplest supported arrangement is a root filesystem plus whatever boot partition arrangement the machine already uses. For many systems that will mean a root filesystem and an existing ESP. For others it may mean a new ESP created just for this installation. The book can work with either choice.
Readers who prefer a split layout may also create additional filesystems, such as a separate /home, /var, or another dedicated mount point. The book will not require those extra partitions, but it will not prevent them either. If a separate filesystem is created, the corresponding mount directory must also exist in the target layout.
A split layout should exist because it serves a maintenance or operational purpose, not because adding partitions feels like progress.
Top-Level Directory Scheme
This book is not planning to mirror the FHS directory names one-for-one. The target layout should use a clearer, deliberately named top-level structure instead of inheriting every traditional path just because history left it lying around.
The intended core directory scheme is under /system:
/system/configurationfor system configuration data./system/binariesfor general user-facing executable programs./system/systembinariesfor executables needed for boot, recovery, and system administration./system/librariesfor shared and static libraries needed by the installed system./system/headersfor development headers./system/sharefor architecture-independent package data such as terminfo records./system/documentationfor packaged manuals, reference material, and other installed documentation./system/toolsfor the helper toolchain used during the build, which may be removed or repurposed after the final system takes over./system/variable- an optional directory for variable data, logs, and other runtime files that do not fit into the above categories.- Traditional FHS paths are compatibility links into
/system, for example:/etc -> /system/configuration,/bin -> /system/binaries,/sbin -> /system/systembinaries,/lib -> /system/libraries,/var -> /system/variable,/home -> /system/users, and/root -> /system/charlie. Common/usr/*paths should likewise link into/system/*, and/system/libshould link to/system/librariesfor packages that derive old-style paths from their configured prefix. /devices, /processes, /system, and others are virtual filesystems that are mounted at runtime and do not need to be created or populated during the build, but will be link targets for /dev, etc./system/charlie- freebsd has a joke about root's full name, 'charlie &', here,/rootshould be a link to it/system/users- a directory for user home directories,/homeshould be a link to it
Other directories may still exist where they make operational sense, especially for boot and mount structure. In practice, that means paths such as /boot, /efi, and any other explicitly chosen mount points may still appear alongside the custom layout. The point is not to ban every conventional name on sight. The point is to make the primary system layout intentional.
Filesystem Tooling
The filesystem tools required on the host depend on which target filesystems the reader chooses. The book does not force a single root filesystem, so the matching userspace tools must be present for the selected format.
- EFI System Partition, if one is being created or reformatted:
dosfstools. - ext2, ext3, or ext4:
e2fsprogs. - XFS:
xfsprogs. - Btrfs:
btrfs-progs. - F2FS:
f2fs-tools. - Swap space, if used: the host must provide the tools that create and manage swap, commonly from
util-linux.
The practical rule is simple: if the target disk layout includes a filesystem, the host must have the userspace tools needed to create it. That should be confirmed before any disk changes are made.
Directories
Once the partition plan is chosen, the mount directory layout should mirror it. At minimum, the target root mount directory is required. If the installation uses an ESP, the chosen mount point for that partition must also exist, whether it is /boot, /efi, or another deliberate location. The custom base directories described above should exist under /system in the target tree: /system/configuration, /system/binaries, /system/systembinaries, /system/libraries, /system/headers, /system/share, and /system/documentation. Any optional partition or dedicated mount point should then map onto one of those paths, or onto another path the reader has chosen on purpose.
Later sections will describe how the target tree is mounted and populated. For now, the important point is that the directory layout follows the partition layout, not the other way around.