IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As I noticed a lot of missing information when trying to implement checking
for missing info. I reimplemented the version information script to be more
robust, and here is the result.
Follow up to ec07c3c80b
This tries to add information about when each option was added. It goes
back to version 183.
The version info is included from a separate file to allow generating it,
which would allow more control on the formatting of the final output.
The verity fec_* parameters allows to use Forward Error Correction to
recover from corruption if hash verification fails.
This adds the options fec_device, fec_offset and fec_roots (sixth
argument) which are the equivalent of the options --fec-device,
--fec-offset and --fec-roots in the veritysetup world.
- fec-device=FILE
- fec-offset=BYTES
- fec-roots=UINT64
See `veritysetup(8)` for more details.
The verity parameter no_superblock allows to format/open an hash device
without the superblock. However, the superblock data must be set to open
the data-device.
This adds the option superblocks (sixth argument) and all the underlying
options which are implied to set the superblock manually if hash device
has no superblock:
- superblock=BOOL
- format=NUMBER (hash version type, 0 for original ChromeOS, 1 for
modern)
- data-block-size=BYTES (max page-size, multiple of 512)
- hash-block-size=BYTES (max page-size, multiple of 512)
- data-blocks=BLOCKS (size of data-device in blocks)
- salt=HEXSTR (salt used at format, max 256 bytes)
- uuid=UUID
- hash=STR (algorithm name for dm-verity used at format, default is
sha256)
See `veritysetup(8)` for more details.
The verity parameter hash_area_offset allows to locate the superblock in
the hash device. It can be used to have a single device which contains
both data and hashes.
This adds the option hash-offset=BYTES (sixth argument) which is the
equivalent of the option --hash-offset in the veritysetup world.
See `veritysetup(8)` for more details.
In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.
This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).
Follow-up for: b66a6e1a58
This adds the support for veritytab.
The veritytab file contains at most five fields, the first four are
mandatory, the last one is optional:
- The first field contains the name of the resulting verity volume; its
block device is set up /dev/mapper/</filename>.
- The second field contains a path to the underlying block data device,
or a specification of a block device via UUID= followed by the UUID.
- The third field contains a path to the underlying block hash device,
or a specification of a block device via UUID= followed by the UUID.
- The fourth field is the roothash in hexadecimal.
- The fifth field, if present, is a comma-delimited list of options.
The following options are recognized only: ignore-corruption,
restart-on-corruption, panic-on-corruption, ignore-zero-blocks,
check-at-most-once and root-hash-signature. The others options will
be implemented later.
Also, this adds support for the new kernel verity command line boolean
option "veritytab" which enables the read for veritytab, and the new
environment variable SYSTEMD_VERITYTAB which sets the path to the file
veritytab to read.
