VERITYSETUP(8)
๐ veritysetup(8) โ the maintenance-commands girlies ๐
okay so bestie. you know how a file can just... lie to you? like the bytes on disk are NOT the bytes you think you're reading? yeah. veritysetup(8) is the queen who fixes that. she lives in the Maintenance Commands section of the manual, and she is obsessed with making sure your block device isn't gaslighting you. ๐ซถ
โจ NAME โจ
veritysetup โ the utility for configuring and managing dm-verity devices. that's it, that's the whole vibe. no cap.
โจ SYNOPSIS โจ
veritysetup <action> [<options>] <action args>
literally that's the shape of every single thing you'll ever run. action, then some options, then the args that action needs. periodt.
โจ DESCRIPTION โจ
veritysetup is a utility for configuring and managing kernel dm-verity devices. ๐
the kernel device-mapper dm-verity target gives you read-only transparent data integrity protection for block devices. read-only, transparent, integrity โ the holy trinity fr fr.
so when you configure a dm-verity device, veritysetup creates a new mapping that applications can access like any regular storage device. nobody has to know. it's giving main character energy but secretly. ๐
the kernel does the verification transparently by comparing each block against pre-computed cryptographic hashes. it uses a Merkle tree (iconic data structure, ate) and it all happens at the kernel level without affecting applications. like, your apps literally do not notice. they're just vibing. โจ
also!! verity devices can be activated during boot through veritytab(5), which is part of systemd(1). so if you're a systemd girlie you're covered. ๐
๐ธ BASIC ACTIONS ๐ธ
veritysetup supports these operations, bestie. learn them, love them, memorize them:
๐ฆ FORMAT
format <data_device> <hash_device>
calculates and permanently stores hash verification data for the data_device. the hash area can be located on the same device after the data, if you specify it with the --hash-offset option. sneaky but legal. ๐
you need to provide the root hash string for device verification or activation. and the root hash must be trusted. like, that's the whole entire point, do not skip this.
the data or hash device argument can be a block device or a file image. and if the hash device path doesn't exist? it will be created as a file. surprise! it's a file now. ๐
<options> can be [--hash, --no-superblock, --format, --data-block-size, --hash-block-size, --data-blocks, --hash-offset, --salt, --uuid, --root-hash-file].
if option --root-hash-file is used, the root hash is stored in hex-encoded text format in <path>.
๐ฆ OPEN
open <data_device> <name> <hash_device> <root_hash>
open <data_device> <name> <hash_device> --root-hash-file <path>
create <name> <data_device> <hash_device> <root_hash> (OBSOLETE syntax)
creates a mapping with <name> backed by device <data_device> and using <hash_device> for in-kernel verification. ๐ฅ
the <root_hash> is a hexadecimal string. hex girlies rise up.
<options> can be [--hash-offset, --no-superblock, --ignore-corruption or --restart-on-corruption, --panic-on-corruption, --ignore-zero-blocks, --check-at-most-once, --root-hash-signature, --root-hash-file, --use-tasklets, --shared].
if option --root-hash-file is used, the root hash is read from <path> instead of the command line parameter. it expects hex-encoded text, without a terminating newline. NO newline. she will not accept a newline. ๐
if --no-superblock is used, you must use the same options as in the initial format operation. same options, bestie. don't get cute.
๐ฆ VERIFY
verify <data_device> <hash_device> <root_hash>
verify <data_device> <hash_device> --root-hash-file <path>
verifies data on data_device using hash blocks stored on hash_device.
this command performs userspace verification; no kernel device is created. so it's the chill, non-committal version. very demure.
the <root_hash> is a hexadecimal string.
if option --root-hash-file is used, the root hash is read from <path> instead of the command line parameter. expects hex-encoded text, without a terminating newline.
<options> can be [--hash-offset, --no-superblock, --root-hash-file].
if --no-superblock is used, you must use the same options as in the initial format operation. again!! same options!!
๐ฆ CLOSE
close <name>
remove <name> (OBSOLETE syntax)
removes existing mapping <name>. bye bestie ๐
<options> can be [--deferred] or [--cancel-deferred].
๐ฆ STATUS
status <name>
reports status for the active verity mapping <name>. just a lil wellness check on your device. how are you doing girl. ๐ฉบ
๐ฆ DUMP
dump <hash_device>
report parameters of the verity device from the on-disk stored superblock. it's like reading her diary but consensually.
<options> can be [--hash-offset].
๐ OPTIONS ๐
okay this is the long part. buckle up. every single flag, no skipping, i promised.
--batch-mode,-qโ do not ask for confirmation. she's on autopilot, she's confident, she's not asking you twice.--cancel-deferredโ cancels a previously configured deferred device removal in theclosecommand. oops, changed my mind ๐--check-at-most-onceโ instructs the kernel to verify blocks only once they are read from the data device, rather than every time.
WARNING: it provides a reduced level of security because only offline tampering of the data device's content will be detected, not online tampering. so like... it's faster but she's not watching the whole time. know that going in. ๐ญ
--data-blocks blocksโ size of the data device used in verification. if not specified, the whole device is used. whole device. all of her.--data-block-size bytesโ used block size for the data device. maximum is the page size used by the kernel. do not exceed her limits, she has boundaries.--debugโ run in debug mode with full diagnostic logs. debug output lines are always prefixed by#. so you can clock them instantly. ๐--deferredโ defers device removal in theclosecommand until the last user closes it. she'll leave when the party's actually over, not before. โจ--error-as-corruptionโ handle device I/O errors the same as data corruption. this option must be combined with--restart-on-corruptionor--panic-on-corruption. it does not go alone, she's a package deal.--fec-device deviceโ use forward error correction (FEC) to recover from corruption if hash verification fails. uses encoding data from the specified device.
the FEC device argument can be a block device or a file image. for format, if the FEC device path doesn't exist, it will be created as a file.
block sizes for data and hash devices must match. also, if the verity data_device is encrypted, the fec_device should be too. matching outfits, bestie. ๐ฏ
FEC calculation covers data, hash area, and optional foreign metadata stored on the same device as the hash tree (additional space after the hash area). the size of this optional additional area protected by FEC is calculated from image sizes, so you must use the same images for activation. same images, always, no switching up.
if the hash device is in a separate image, metadata covers the entire image after the hash area.
the metadata ends on the FEC area offset if the hash and FEC device are in the image.
--fec-offset bytesโ this is the offset, in bytes, from the start of the FEC device to the beginning of the encoding data. ๐--fec-roots numberโ number of generator roots. this equals the number of parity bytes in the encoding data. inRS(M, N)encoding, the number of roots isM-N.Mis255, andM-Nis between2and24(including). math girlies, this one's for you. ๐งฎ--format numberโ specifies the hash version type. format type0is the original Chrome OS version. format type1is the current version.0is vintage,1is the moment.--hash hashโ hash algorithm for dm-verity. for default, see--helpoption. she won't tell you here, go ask--help.--hash-block-size bytesโ used block size for the hash device. maximum is the page size used by the kernel. same boundary situation as before.--hash-offset bytesโ offset of hash area/superblock onhash_device. value must be aligned with the disk sector offset. alignment is not optional, she's picky about it.--help,-?โ show help text and default parameters. also where you find out the default--hash. go look, bestie.--ignore-corruption,--restart-on-corruption,--panic-on-corruptionโ defines what to do if a data integrity problem (data corruption) is detected.
without these options, the kernel fails the I/O operation with an I/O error. with the --ignore-corruption option, the corruption is only logged. with --restart-on-corruption or --panic-on-corruption, the kernel is restarted (panicked) immediately. (you have to provide a way to avoid restart loops.) like genuinely, set up your escape hatch first. ๐ญ
use these options only for very specific cases. very. specific. cases. do not freestyle this.
--ignore-zero-blocksโ instructs the kernel not to verify blocks expected to contain zeroes and always directly return zeroes instead. zeroes in, zeroes out, no questions asked.
use this option only in very specific cases. same energy as above. ๐ฉ
--no-superblockโ create or use dm-verity without a permanent on-disk superblock. no receipt, no record, just vibes (and you better remember your format options).--root-hash-file file*โ path to file with stored root hash in hex-encoded text.--root-hash-signature file*โ a path to the root hash signature file used to verify the root hash (in kernel). this feature requires a Linux kernel version5.4or more recent. old kernels need not apply. โจ--salt=hex stringโ salt used for formatting or verification. format is a hexadecimal string. a lil seasoning for your hashes ๐ง--sharedโ allows the data device to be used in shared mode. the data device is not checked for exclusive access before the device activation and may be mapped in multiple verity mappings. she's polyamorous now, she's fine with sharing.--usageโ show short option help. the sparknotes version. ๐--use-taskletsโ try to use kernel tasklets in the dm-verity driver for performance reasons. this option is available since Linux kernel version6.0. new kernel, new tricks.--uuid UUIDโ use the provided UUID for theformatcommand instead of generating a new one.
the UUID must be provided in standard UUID format, e.g., 12345678-1234-1234-1234-123456789abc. cute lil pattern, isn't she.
--verbose,-vโ print more information on command execution. she's telling you everything now, she's oversharing, we love that. ๐ฃ๏ธ--version,-Vโ show the program version. ๐
๐ REPORTING BUGS ๐
okay bestie, found a bug? ๐ do NOT suffer in silence, go tell the maintainers!
- Report bugs at the cryptsetup mailing list
<cryptsetup@lists.linux.dev>๐ - or in the Issues project section at
<https://gitlab.com/cryptsetup/cryptsetup/-/issues/new>๐ธ
Please attach the output of the failed command with--debugoption added. ๐ซถ seriously, this is the move. no--debugoutput and the devs are just out here vibing blind. give them the receipts. ๐งพโจ
๐ SEE ALSO ๐
- Cryptsetup FAQ โ
<https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions>๐ cryptsetup(8),integritysetup(8)andveritysetup(8)๐
๐ CRYPTSETUP ๐
Part of cryptsetup project <https://gitlab.com/cryptsetup/cryptsetup/>. ๐ that's the whole family right there, and yeah, veritysetup is part of it, iykyk. ๐
and that's the whole page, bestie!! ๐ฆ you just read the entirety of VERITYSETUP(8) from the cryptsetup project โ veritysetup 2.8.8, dated 2026-09-07 โจ go forth and verify all the things, you absolute main character. slay, no cap. ๐
๐๐
๐ฆ where this page comes from
- arch rolling: cryptsetup 2.8.8-1 ยท GPL-2.0-or-later
- fedora 44: veritysetup 2.8.8-1.fc44 ยท GPL-2.0-or-later WITH cryptsetup-OpenSSL-exception AND LGPL-2.1-or-later WITH cryptsetup-OpenSSL-exception
- nixpkgs unstable: cryptsetup 2.8.8
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms