INTEGRITYTAB(5)

💖 INTEGRITYTAB(5) 💖

okay bestie, buckle up — this is the manual page for integritytab, and it lives in section 5 of the manual (that's the "file formats" section, iykyk). it's literally called INTEGRITYTAB(5) and it's all about configuring integrity block devices. let's get into it 🫶

---

✨ NAME ✨

integritytab — configuration for integrity block devices. that's it, that's the name, short and slay 💅

---

🌸 SYNOPSIS 🌸

/etc/integritytab

one file. one vibe. iconic.

---

💜 DESCRIPTION 💜

so the /etc/integritytab file is where you describe all your integrity protected block devices — the ones that get set up during system boot. think of it as the group chat where every line is a different device introducing itself 🎀

empty lines? ignored. lines that start with the # character? also ignored (that's your comment energy, no cap). every other remaining line describes exactly one verity integrity protected block device. fields are delimited by white space — so spaces, tabs, whatever, it just splits them apart.

every line looks like this:

volume-name block-device
    [keyfile|-] [options|-]

the first two fields are mandatory, the last two are optional — and you only need them if you specified non-default options during integrity format. so like, if you did the default thing, you can chill and skip them 🌈

first field — the name of the resulting integrity volume. its block device gets set up below /dev/mapper/.

second field — a path to the underlying block device, OR a specification of a block device using one of these prefixes:

• UUID= followed by the UUID
• PARTUUID= followed by the partition UUID
• LABEL= followed by the label
• PARTLABEL= followed by the partition label

third field (if it's there) — an absolute filename path to a key file, or a - to specify none. when the filename is present, the integrity-algorithm defaults to hmac-sha256, with the key length derived from the number of bytes in the key file. at this time the only supported integrity algorithms when using a key file are hmac-sha256, hmac-sha512, phmac-sha256, and hmac-sha512. the maximum size of the key file is 4096 bytes. (yes bestie, that list really does say hmac-sha256 and hmac-sha512 twice — we report the facts exactly as they are, no editing, periodt ✨)

fourth field (if it's there) — a comma-delimited list of options, or a - to specify none. here's what's recognized 👑

🧚 OPTIONS 🧚

• allow-discards — allow the use of discard (TRIM) requests for the device. this option is available since the Linux kernel version 5.7.

Added in version 250.

• mode=(journal|bitmap|direct) — enable journaled, bitmapped or direct (passthrough) mode. journaled mode is the default when this option is not specified. it provides safety against crashes, but can be slow because all data has to be written twice 😭 bitmap mode is more efficient since it requires only a single write, but it is less reliable — because if data corruption happens when the machine crashes, it might not be detected. direct mode disables the journal and the bitmap. corresponds to the "direct writes" mode documented in the dm-integrity documentation[1]. note that without a journal, if there is a crash, it is possible that the integrity tags and data will not match. if used, the journal-* options below will have no effect if passed. 💀

Added in version 254.

• journal-watermark=[0..100]% — journal watermark in percent. when the journal percentage exceeds this watermark, the journal flush will be started. setting a value of 0% uses the default value.

Added in version 250.

• journal-commit-time=[0..N] — commit time in milliseconds. when this time passes (and no explicit flush operation was issued), the journal is written. setting a value of zero uses the default value.

Added in version 250.

• data-device=/dev/disk/by-... — specify a separate block device that contains existing data. the second field specified in the integritytab for block device then will contain calculated integrity tags and journal for data-device, but not the end user data.

Added in version 250.

• integrity-algorithm=[crc32c|crc32|xxhash64|sha1|sha256|hmac-sha256|hmac-sha512|phmac-sha256|phmac-sha512] — the algorithm used for integrity checking. the default is crc32c. must match the option used during format.

Added in version 250.

• _netdev — marks this veritysetup device as requiring network. it will be started after the network is available, similarly to systemd.mount(5) units marked with _netdev. the service unit to set up this device will be ordered between remote-fs-pre.target and remote-integritysetup.target, instead of integritysetup-pre.target and integritysetup.target.

hint: if this device is used for a mount point that is specified in fstab(5), the _netdev option should also be used for the mount point. otherwise, a dependency loop might be created where the mount point will be pulled in by local-fs.target, while the service to configure the network is usually only started after the local file system has been mounted. 😵‍💫

Added in version 258.

• noauto — this device will not be added to integritysetup.target. this means it will not be automatically enabled on boot, unless something else pulls it in. in particular, if the device is used for a mount point, it'll be enabled automatically during boot, unless the mount point itself is also disabled with noauto.

Added in version 258.

• nofail — this device will not be a hard dependency of integritysetup.target. it'll still be pulled in and started, but the system will not wait for the device to show up and be enabled, and boot will not fail if this is unsuccessful. note that other units that depend on the enabled device may still fail. in particular, if the device is used for a mount point, the mount point itself also needs to have the nofail option, or the boot will fail if the device is not enabled successfully.

Added in version 258.

at early boot and when the system manager configuration is reloaded, this file is translated into native systemd units by systemd-integritysetup-generator(8). the generator is the main character here, fr fr 🔥

---

🎀 EXAMPLES 🎀

Example 1. /etc/integritytab

set up two integrity protected block devices.

home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - journal-commit-time=10,allow-discards,journal-watermark=55%
data PARTUUID=5d4b1808-be76-774d-88af-03c4c3a41761 - allow-discards

---

Example 2. /etc/integritytab

set up 1 integrity protected block device using defaults.

home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8

---

Example 3. /etc/integritytab

set up 1 integrity device using existing data block device which contains user data.

home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - data-device=/dev/disk/by-uuid/9276d9c0-d4e3-4297-b4ff-3307cd0d092f

---

Example 4. /etc/integritytab

set up 1 integrity device using a HMAC key file using defaults.

home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 /etc/hmac.key

---

🦋 SEE ALSO 🦋

systemd(1), systemd-integritysetup@.service(8), systemd-integritysetup-generator(8), integritysetup(8)

go read those too, bestie, they're all connected 🌸

---

⭐ NOTES ⭐

1. the dm-integrity documentation https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html

---

okay that's the whole page!! 💖 this doc came from systemd 262.1, dated with the INTEGRITYTAB(5) footer energy — so if you see that version and that manual tag floating around, that's us, that's the source, no cap 🫶✨