You add an fstab entry for a new data disk, reboot, and the machine drops to an emergency shell instead of coming up. Why can one fstab line stop the whole boot, and which mount options let a non-critical filesystem fail without taking the system down?

## What an fstab line becomes at boot On any current distribution, `/etc/fstab` is not read by a shell script at boot; `systemd-fstab-generator` parses it early and emits a `.mount` unit per entry, plus an `.automount` unit where you asked for one. The unit is named after the escaped mount point — `/data` becomes `data.mount`. Ordinary local filesystems get pulled into `local-fs.target`, and remote ones into `remote-fs.target`. Because those units are *required*, not merely wanted, a single failing mount fails the target that ordinary services depend on. When that happens, systemd stops the normal boot and starts `emergency.target`: a single-user shell on the console that prompts for the root password. On a laptop this is an inconvenience. On a rack machine or a cloud instance it is an outage that a reboot will not fix, because the shell waits forever and nothing else starts — no SSH, no network. This is why an unrelated fstab typo is one of the classic "the server never came back" incidents. ## Which failures reach that state - **The device does not exist.** The mount unit waits for the device unit to appear (default timeout 90 seconds), then fails. Typos in a UUID land here, as do disks that were detached, and disks whose UUID changed because someone reformatted them. - **The filesystem will not mount.** Wrong `fstype`, an option the filesystem rejects, or corruption. - **fsck fails.** The sixth field, the pass number, controls this: `1` for root, `2` for other locally checked filesystems, `0` to skip. A filesystem that needs manual repair fails its `systemd-fsck@` unit and takes the mount with it. ## The options that make a mount optional **`nofail`** — the important one. The mount unit is still generated and still attempted, but it is no longer a hard requirement of `local-fs.target`. Boot proceeds; the failure is visible in the logs. Every filesystem that is not required for the machine to be reachable should carry it. **`noauto`** — not mounted at boot at all. The entry exists so that `mount /data` works with just the mount point, and `mount -a` skips it. Useful for removable media and for filesystems a service mounts itself. **`_netdev`** — declares that the filesystem needs the network, which orders it after the network is up and puts it under `remote-fs.target` instead of `local-fs.target`. Required for iSCSI, NFS-backed loopbacks and network block devices; without it the mount is attempted before an interface has an address. **`x-systemd.device-timeout=`** — how long to wait for the backing device before giving up. The default is 90 seconds, and combined with a missing device that is 90 seconds of a boot that looks hung. Setting `x-systemd.device-timeout=10s` alongside `nofail` makes an absent optional disk cost ten seconds instead of a minute and a half. **`x-systemd.automount`** (usually with `x-systemd.idle-timeout=`) — creates an automount point instead of a mount: nothing is mounted until something first touches the path, at which point the mount is performed. This removes the filesystem from the boot path entirely, which is the strongest form of "do not let this block me". ```bash # optional data disk that must never block the boot UUID=6f3c1e6a-06a1-4c39-9ad3-2f9f2b7f8a11 /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2 ``` ## The discipline around editing fstab Editing the file changes nothing by itself. Run `systemctl daemon-reload` so the generator re-runs and the new units exist, then `mount -a` to prove the entries actually work on the running system. `findmnt --verify` parses fstab and reports unreachable sources, unknown filesystem types and duplicate mount points before you find them the hard way. Only after both are clean should a remote machine be rebooted. ## Recovering a machine that is already stuck If you have console access, the emergency shell can be logged into with the root password, and the fix is to remount root writable (`mount -o remount,rw /`), correct the entry and reboot. If you do not, the recovery is out-of-band: boot with `systemd.unit=emergency.target` or `init=/bin/sh` appended to the kernel command line from the bootloader, or attach the disk to a rescue instance and edit fstab there. That asymmetry — trivially fixable at the console, painful without one — is exactly the argument for `nofail` as a default habit.