convert-fstab-services 1 administrator commands nosh
convert-fstab-services convert fstab 5 into services write-volume-service-bundles write the service bundles for a given volume
`system-control` convert-fstab-services --etc-bundle --bundle-root root `system-control` write-volume-service-bundles --etc-bundle --bundle-root root --want-fsck fstype source directory options

## Description

These (sub)commands generate sets of service bundles that contain scripts, dependencies, and autoboot dependency configuration information appropriate for mounting, unmounting, and checking a volume. See system-control 8 for an explanation of service bundles.

The bundles generated by these subcommands are written in the current directory (or in the root directory). They are not enabled by the conversion process, but can be started and enabled as they stand, with the `start` and `preset` subcommands, just like any other service bundle. With `preset` the --fstab option is appropriate of course. (It is `preset` that handles the `noauto` option in fstab 5.)

The assumption is that all service bundles are under one common root and all target bundles under another; so service-to-service dependencies and orderings can be relative pathnames whilst service-to-target and target-to-service dependencies and orderings have to be absolute pathnames. The --etc-bundle option changes this assumption, such that target bundles are now assumed to be reachable with relative pathnames from the converted service bundle; as is the case for special early bootstrap service bundles that live in `/etc/service-bundles/services/`. It also forces the bundle to be marked as an `EarlySupervise` bundle whose `supervise/` directory lives in a tmpfs.

### Converting the whole of fstab 5

The `convert-fstab-services` subcommand takes the records from the flat file table in `/etc/fstab` (see fstab 5) and generates from them a set of service bundles for each record.

console-flat-table-viewer 1 explains what a flat file table is. getent 1 does not support reading the fstab 5 table. To see this table as `convert-fstab-services` sees it, run:

    (
        printf '%s\t' source directory fstype options 'dump\040frequency' 'pass\040number'
        printf '\n'
        cat /etc/fstab
    ) |
    console-flat-table-viewer --header-count 1

- For each non-swap entry:

  - It acts as if it had run `write-volume-service-bundles` with the values from the entry, discarding the "dump frequency" column of the table. If the entry specifies a "pass number" that is greater than zero, it acts as if the --want-fsck option had been passed.

- For each swap entry the "source" column is taken to be a `device` special device filename and the "options" column may contain various flags.

  - It always creates a `swap@device` bundle running swapon 8 at service startup and swapoff 8 at service shutdown. The bundle is created as `wanted-by/` either the system `swapauto.target` or the system `swaplate.target`, so that it is started during autoboot when it is enabled. The choice depends from whether the entry is marked `late`.

    If the entry is marked `discard` then it creates a bundle that passes the --discard flag to swapon 8. If the entry is marked `pri=N` then it creates a bundle that passes the --priority N flag.

    Not all swapon 8 utilities support these options.

  - It always creates a `dump@device` bundle running dumpon 8 at service startup and dumpoff 8 at service shutdown. The bundle is created as `wanted-by/` the system `dumpauto.target`, so that it is started during autoboot when it is enabled.

### Generating services for a single volume

The `write-volume-service-bundles` subcommand writes service bundles for a single volume described with its command-line arguments.

- It always creates a `mount@directory` bundle that at service startup mounts source there with mount 8 and the options options (if any), and at service shutdown unmounts it with umount 8. (The `auto`, `noauto`, `nofail`, and `_netdev` options have no meaning to the actual mount process and are not passed through to the mount options used in the service bundle.)

  The bundle is created as `wanted-by/` the system `local-fs.target` or the system `remote-fs.target`, depending from the filesystem type fstype and whether the options contains `_netdev`. This so that it is started during autoboot when it is enabled. The list of types that are considered to be "remote" is a superset of the old Debian list from `mountall.sh`, with a few additions from the BSDs. The `_netdev` option overrides this list and forces a bundle to be unconditionally considered "remote".

  If it detects a FUSE mount, it makes the bundle `wants/` and `after/` a bundle to load the FUSE kernel module. Similarly, if the fstype is `efivarfs`, it makes the bundle `wants/` and `after/` a bundle to load that kernel module.

  "API" filesystems (see system-control 1) and the root filesystem are specially handled:

  - They are assumed already mounted by the time that service management starts, and are thus mounted with the "remount"/"update" flag.

  - The root is required to remain mounted beyond service management termination, and thus it is merely remounted/updated to read-write at start and to read-only at stop.

- If the --want-fsck option is used, it creates a `fsck@directory` bundle, running monitored-fsck 1 at service startup. Any `fsck@directory` bundle that is created is ordered `before/` the respective `mount@directory` bundle, and is `wanted-by/` it. So when the bundle is enabled fsck 8 is run (monitored, on source) before the volume is actually mounted.

- If source ends in `.bde`, it creates a `gbde@source` bundle, running gbde 8 at service startup and shutdown (to attach `source` to `source.bde` and detach it), removing that suffix from source to generate the main bundles. Any `gbde@source` bundle that is created is ordered `before/` the respective `fsck@directory` and `mount@directory` bundle, and is `wanted-by/` them. So when the main bundles are started gbde 8 is run before the volume is actually checked and mounted.

- If source ends in `.eli`, it creates a `geli@source` bundle, running geli 8 at service startup and shutdown (to attach `source` to `source.eli` and detach it), removing that suffix from source to generate the main bundles. Any `geli@source` bundle that is created is ordered `before/` the respective `fsck@directory` and `mount@directory` bundle, and is `wanted-by/` them. So when the main bundles are started geli 8 is run before the volume is actually checked and mounted.

## Author

Jonathan de Boyne Pollard