neulab/tldr huggingface dataset:
If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.
For example, if a certificate used to sign an entry is expired and has a KeyUsage extension that does not allow it to sign a file, the jarsigner command exits with code 12 (=4+8) when the -strict option is specified.
Note: Exit codes are reused because only the values from 0 to 255 are legal on Unix-based operating systems.
The following sections describes the names, codes, and descriptions of the errors and warnings that the jarsigner command can issue.
FAILURE Reasons why the jarsigner command fails include (but are not limited to) a command line parsing error, the inability to find a keypair to sign the JAR file, or the verification of a signed JAR fails.
failure Code 1. The signing or verifying fails.
SEVERE WARNINGS Note: Severe warnings are reported as errors if you specify the -strict option.
Reasons why the jarsigner command issues a severe warning include the certificate used to sign the JAR file has an error or the signed JAR file has other problems.
hasExpiredCert Code 4. This jar contains entries whose signer certificate has expired.
notYetValidCert Code 4. This jar contains entries whose signer certificate is not yet valid.
chainNotValidated Code 4. This jar contains entries whose certificate chain cannot be correctly validated.
badKeyUsage Code 8. This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.
badExtendedKeyUsage Code 8. This jar contains entries whose signer certificate's ExtendedKeyUsage extension doesn't allow code signing.
badNetscapeCertType Code 8. This jar contains entries whose signer certificate's NetscapeCertType extension doesn't allow code signing.
hasUnsignedEntry Code 16. This jar contains unsigned entries which have not been integrity-checked.
notSignedByAlias Code 32. This jar contains signed entries which are not signed by the specified alias(es).
aliasNotInStore Code 32. This jar contains signed entries that are not signed by alias in this keystore.
INFORMATIONAL WARNINGS Informational warnings include those that are not errors but regarded as bad practice. They do not have a code.
hasExpiringCert This jar contains entries whose signer certificate will expire within six months.
noTimestamp This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this JAR file after the signer certificate's expiration date (YYYY-MM-DD) or after any future revocation date.
SIGN A JAR FILE Use the following command to sign bundle.jar with the private key of a user whose keystore alias is jane in a keystore named mystore in the working directory and name the signed JAR file sbundle.jar:
jarsigner -keystore /working/mystore -storepass <keystore password> -keypass <private key password> -signedjar sbundle.jar bundle.jar jane
There is no -sigfile specified in the previous command so the generated .SF and .DSA files to be placed in the signed JAR file have default names based on the alias name. They are named JANE.SF and JANE.DSA.
If you want to be prompted for the store password and the private key password, then you could shorten the previous command to the following:
jarsigner -keystore /working/mystore -signedjar sbundle.jar bundle.jar jane
If the keystore is the default keystore (.keystore in your home directory), then you do not need to specify a keystore, as follows:
jarsigner -signedjar sbundle.jar bundle.jar jane
If you want the signed JAR file to overwrite the input JAR file (bundle.jar), then you do not need to specify a -signedjar option, as follows:
jarsigner bundle.jar jane
VERIFY A SIGNED JAR FILE To verify a signed JAR file to ensure that the signature is valid and the JAR file was not been tampered with, use a command such as the following:
jarsigner -verify sbundle.jar
When the verification is successful, jar verified is displayed. Otherwise, an error message is displayed. You can get more information when you use the -verbose option. A sample use of jarsigner with the- verbose option follows:
jarsigner -verify -verbose sbundle.jar 198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF 199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF 1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA smk   2752 Fri Sep 26 16:12:30 PDT 1997 AclEx.class smk    849 Fri Sep 26 16:12:46 PDT 1997 test.class s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore jar verified.
VERIFICATION WITH CERTIFICATE INFORMATION If you specify the -certs option with the -verify and -verbose options, then the output includes certificate information for each signer of the JAR file. The information includes the certificate type, the signer distinguished name information (when it is an X.509 certificate), and in parentheses, the keystore alias for the signer when the public key certificate in the JAR file matches the one in a keystore entry, for example:
jarsigner -keystore /working/mystore -verify -verbose -certs myTest.jar 198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF 199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF 1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA 208 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.SF 1087 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.DSA smk   2752 Fri Sep 26 16:12:30 PDT 1997 Tst.class X.509, CN=Test Group, OU=Java Software, O=Oracle, L=CUP, S=CA, C=US (javatest) X.509, CN=Jane Smith, OU=Java Software, O=Oracle, L=cup, S=ca, C=us (jane) s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore jar verified.
If the certificate for a signer is not an X.509 certificate, then there is no distinguished name information. In that case, just the certificate type and the alias are shown. For example, if the certificate is a PGP certificate, and the alias is bob, then you would get: PGP, (bob).
VERIFICATION THAT INCLUDES IDENTITY DATABASE SIGNERS If a JAR file was signed with the JDK 1.1 javakey tool, and the signer is an alias in an identity database, then the verification output includes an i. If the JAR file was signed by both an alias in an identity database and an alias in a keystore, then both k and i appear.
When the -certs option is used, any identity database aliases are shown in brackets rather than the parentheses used for keystore aliases, for example:
jarsigner -keystore /working/mystore -verify -verbose -certs writeFile.jar 198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF 199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF 1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA 199 Fri Sep 27 12:22:30 PDT 1997 META-INF/DUKE.SF 1013 Fri Sep 27 12:22:30 PDT 1997 META-INF/DUKE.DSA smki   2752 Fri Sep 26 16:12:30 PDT 1997 writeFile.html X.509, CN=Jane Smith, OU=Java Software, O=Oracle, L=cup, S=ca, C=us (jane) X.509, CN=Duke, OU=Java Software, O=Oracle, L=cup, S=ca, C=us [duke] s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope jar verified.
Note: The alias duke is in brackets to denote that it is an identity database alias, and not a keystore alias.
JDK 1.1 COMPATIBILITY The keytool and jarsigner tools replace the javakey tool in JDK 1.1. These new tools provide more features than javakey, including the ability to protect the keystore and private keys with passwords, and the ability to verify signatures in addition to generating them.
The new keystore architecture replaces the identity database that javakey created and managed. There is no backward compatibility between the keystore format and the database format used by javakey in JDK 1.1. However, be aware of the following:
• It is possible to import the information from an identity database into a keystore through the keytool -identitydb command.
• The jarsigner command can sign JAR files that were signed with the javakey command.
• The jarsigner command can verify JAR files signed with javakey. The jarsigner command recognizes and can work with signer aliases that are from a JDK 1.1 identity database rather than a JDK keystore.
UNSIGNED JARS Unsigned JARs have the default privileges that are granted to all code.
SIGNED JARS Signed JARs have the privilege configurations based on their JDK 1.1.n identity and policy file status as described. Only trusted identities can be imported into the JDK keystore.
Default Privileges Granted to All Code
Identity in 1.1 database: No Trusted identity imported into Java keystore from 1.1. database: No Policy file grants privileges to identity/alias: No
Identity in 1.1 database: No Trusted identity imported into Java keystore from 1.1. database: Yes Policy file grants privileges to identity/alias: No
Identity in 1.1 database: Yes/Untrusted Trusted identity imported into Java keystore from 1.1. database: No Policy file grants privileges to identity/alias: No See 3 in Notes Regarding Privileges of Signed JARs.
Identity in 1.1 database: Yes/Untrusted Trusted identity imported into Java keystore from 1.1. database: No Policy file grants privileges to identity/alias: Yes See 1 and 3 in Notes Regarding Privileges of Signed JARs.
Default Privileges and Policy File Privileges Granted
Identity in 1.1 database: No Trusted identity imported into Java keystore from 1.1. database: Yes Policy file grants privileges to identity/alias: Yes
Identity in 1.1 database: Yes/Trusted Trusted identity imported into Java keystore from 1.1. database: Yes Policy file grants privileges to identity/alias: Yes See 2 in Notes Regarding Privileges of Signed JARs.
All Privileges Granted
Identity in 1.1 database: Yes/Trusted Trusted identity imported into Java keystore from 1.1. database: No Policy file grants privileges to identity/alias: No
Identity in 1.1 database: Yes/Trusted Trusted identity imported into Java keystore from 1.1. database: Yes Policy file grants privileges to identity/alias: No See 1 in Notes Regarding Privileges of Signed JARs.
Identity in 1.1 database: Yes/Trusted Trusted identity imported into Java keystore from 1.1. database: No Policy file grants privileges to identity/alias: Yes See 1 in Notes Regarding Privileges of Signed JARs.
Notes Regarding Privileges of Signed JARs
1.  If an identity or alias is mentioned in the policy file, then it must be imported into the keystore for the policy file to have any effect on privileges granted.
2.  The policy file/keystore combination has precedence over a trusted identity in the identity database.
3.  Untrusted identities are ignored in the Java platform.
• jar
• keytool
• Trail: Security Features in Java SE at http://docs.oracle.com/javase/tutorial/security/index.html
SOLO(1)                      General Commands Manual                     SOLO(1)
solo - command line interface for SoloKeys
solo [OPTIONS] COMMAND [ARGS]...
Commands: genkey Generates key pair that can be used for Solo signed firmware...
key    Interact with Solo keys, see subcommands.
ls     List Solos (in firmware or bootloader mode) and potential Solos...
mergehex Merges hex files, and patches in the attestation key.
monitor Reads Solo Hacker serial output from USB serial port...
program Program a key.
sign   Signs a firmware hex file, outputs a .json file that can be used...
version Version of python-solo library and tool.
This manual page was written by Philip Rinn <rinni@inventati.org>.
MANDB(8)                       Manual pager utils                       MANDB(8)
mandb - create or update the manual page index caches
mandb [-dqsucpt?V] [-C file] [manpath] mandb [-dqsut] [-C file] -f filename ...
mandb is used to initialise or manually update index database caches. The caches contain information relevant to the current state of the manual page system and the information stored within them is used by the man-db utilities to enhance their speed and functionality.
When creating or updating an index, mandb will warn of bad ROFF .so requests, bogus manual page filenames and manual pages from which the whatis cannot be parsed.
Supplying mandb with an optional colon-delimited path will override the internal system manual page hierarchy search path, determined from information found within the man-db configuration file.
mandb can be compiled with support for any one of the following database types.
Name          Async   Filename ────────────────────────────────────── Berkeley db   Yes     index.bt GNU gdbm      Yes     index.db UNIX ndbm     No      index.(dir|pag)
Those database types that support asynchronous updates provide enhanced speed at the cost of possible corruption in the event of unusual termination.  In an unusual case where this has occurred, it may be necessary to rerun mandb with the -c option to re-create the databases from scratch.
-q, --quiet Produce no warnings.
-s, --no-straycats Do not spend time looking for or adding information to the databases regarding stray cats.
-p, --no-purge Do not spend time checking for deleted manual pages and purging them from the databases.
-c, --create By default, mandb will try to update any previously created databases.  If a database does not exist, it will create it.  This option forces mandb to delete previous databases and re-create them from scratch, and implies --no-purge.  This may be necessary if a database becomes corrupt or if a new database storage scheme is introduced in the future.
-u, --user-db Create user databases only, even with write permissions necessary to create system databases.
-t, --test Perform correctness checks on manual pages in the hierarchy search path.  With this option, mandb will not alter existing databases.
-f, --filename Update only the entries for the given filename.  This option is not for general use; it is used internally by man when it has been compiled with the MAN_DB_UPDATES option and finds that a page is out of date.  It implies -p and disables -c and -s.
-?, --help Show the usage message, then exit.
-V, --version Show the version, then exit.
1      Usage, syntax, or configuration file error.
2      Operational error.
3      A child process failed.
The following warning messages can be emitted during database building.
<filename>: whatis parse for page(sec) failed An attempt to extract whatis line(s) from the given <filename> failed.  This is usually due to a poorly written manual page, but if many such messages are emitted it is likely that the system contains non-standard manual pages which are incompatible with the man-db whatis parser.  See the WHATIS PARSING section in lexgrog(1) for more information.
<filename>: is a dangling symlink <filename> does not exist but is referenced by a symbolic link. Further diagnostics are usually emitted to identify the <filename> of the offending link.
<filename>: bad symlink or ROFF `.so' request <filename> is either a symbolic link to, or contains a ROFF include request to, a non existent file.
<filename>: ignoring bogus filename The <filename> may or may not be a valid manual page but its name is invalid.  This is usually due to a manual page with sectional extension <x> being put in manual page section <y>.
<filename_mask>: competing extensions The wildcard <filename_mask> is not unique.  This is usually caused by the existence of both a compressed and uncompressed version of the same manual page.  All but the most recent are ignored.
/etc/man_db.conf man-db configuration file.
/var/cache/man/index.(bt|db|dir|pag) An FHS compliant global index database cache.
Older locations for the database cache included:
/usr/man/index.(bt|db|dir|pag) A traditional global index database cache.
/var/catman/index.(bt|db|dir|pag) An alternate or FSSTND compliant global index database cache.
lexgrog(1), man(1), manpath(5), catman(8)
The WHATIS PARSING section formerly in this manual page is now part of lexgrog(1).
autojump(1)                                                          autojump(1)
NAME autojump - a faster way to navigate your filesystem
DESCRIPTION autojump is a faster way to navigate your filesystem.  It works by maintaining a database of the directories you use the most from the command line.
Directories must be visited first before they can be jumped to.
USAGE j is a convenience wrapper function around autojump.  Any option that can be used with autojump can be used with j and vice versa.
• Jump To A Directory That Contains foo:
j foo
• Jump To A Child Directory:
Sometimes it's convenient to jump to a child directory (sub-directory of current directory) rather than typing out the full name.
jc bar
• Open File Manager To Directories (instead of jumping):
Instead of jumping to a directory, you can open a file explorer window (Mac Finder, Windows Explorer, GNOME Nautilus, etc.) to the directory instead.
jo music
Opening a file manager to a child directory is also supported:
jco images
• Using Multiple Arguments:
Let's assume the following database:
30   /home/user/mail/inbox 10   /home/user/work/inbox
j in would jump into /home/user/mail/inbox as the higher weighted entry.  However you can pass multiple arguments to autojump to prefer a different entry.  In the above example, j w in would then change directory to /home/user/work/inbox.
For more options refer to help:
autojump --help
KNOWN ISSUES • autojump does not support directories that begin with -.
• For bash users, autojump keeps track of directories by modifying $PROMPT_COMMAND.  Do not overwrite $PROMPT_COMMAND:
export PROMPT_COMMAND="history -a"
Instead append to the end of the existing $PROMPT_COMMAND:
export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ;} history -a"
REPORTING BUGS For any questions or issues please visit:
https://github.com/wting/autojump/issues
AUTHORS autojump was originally written by Joël Schaerer, and currently maintained by William Ting.  More contributors can be found in AUTHORS.
COPYRIGHT Copyright © 2016 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.  This is free software: you are free to change and redistribute it.  There is NO WARRANTY, to the extent permitted by law.
docker-rmi - Remove one or more images
docker rmi [OPTIONS] IMAGE [IMAGE...]
Alias for docker image rm.
-f, --force[=false]      Force removal of the image
-h, --help[=false]      help for rmi
--no-prune[=false]      Do not delete untagged parents
GNUPLOT(1)                   General Commands Manual                  GNUPLOT(1)
gnuplot - an interactive plotting program
gnuplot [X11 options] [options] [file ...]
Gnuplot is a command-driven interactive plotting program.
If file names are given on the command line, gnuplot loads and executes each file in the order specified, and exits after the last file is processed.  If no files are given, gnuplot prompts for interactive commands.
Here are some of its features:
Plots any number of functions, built up of C operators, C math library functions, and some things C doesn't have like **, sgn(), etc.
User-defined constants and functions.
All computations performed in the complex domain.  Just the real part is plotted by default, but functions like imag() and abs() and arg() are available to override this.
Many presentation styles for plotting user data from files, including surface-fitting, error bars, boxplots, histograms, heat maps, and simple manipulation of image data.  There is an on-line demo collection at http://gnuplot.info/demo
Nonlinear least-squares fitting.
2D and 3D plots with mouse-controlled zooming, rotation, and hypertext.
Shell escapes and command line substitution.
Load and save capability.
Support for a huge variety of output devices and file formats.
-p, --persist lets plot windows survive after main gnuplot program exits.
-c scriptname ARG1 ARG2 ..., load script using gnuplot's "call" mechanism and pass it the remainder of the command line as arguments
-d, --default settings.  Do not read from gnuplotrc or ~/.gnuplot on entry.
-e "command list" executes the requested commands before loading the next input file.
-s, --slow wait for slow font initialization rather than continuing with an error.
-h, --help print summary of usage
-V show current version
X11 OPTIONS For terminal type x11, gnuplot accepts the standard X Toolkit options and resources such as geometry, font, and background. See the X(1) man page for a description of common options.  For additional X options specific to gnuplot, type help x11 on the gnuplot command line. These options have no effect on other terminal types.
A number of shell environment variables are understood by gnuplot.  None of these are required.
GNUTERM The name of the terminal type to be used by default.  This can be overridden by the gnuplotrc or .gnuplot start-up files and, of course, by later explicit "set terminal" commands.
GNUHELP The pathname of the HELP file (gnuplot.gih).
HOME   The name of a directory to search for a .gnuplot file.
PAGER  An output filter for help messages.
SHELL  The program used for the "shell" command.
FIT_SCRIPT Specifies a gnuplot command to be executed when a fit is interrupted---see "help fit".
FIT_LOG The name of the logfile maintained by fit.
GNUPLOT_LIB Additional search directories for data and command files. The variable may contain a single directory name, or a list of directories separated by ':'. The contents of GNUPLOT_LIB are appended to the "loadpath" variable, but not saved with the "save" and "save set" commands.
GDFONTPATH Several gnuplot terminal drivers access TrueType fonts via the gd library.  This variable gives the font search path for these drivers.
GNUPLOT_DEFAULT_GDFONT The default font for the terminal drivers that access TrueType fonts via the gd library.
GNUPLOT_FONTPATH The font search path used by the postscript terminal. The format is the same as for GNUPLOT_LIB. The contents of GNUPLOT_FONTPATH are appended to the "fontpath" variable, but not saved with the "save" and "save set" commands.
GNUPLOT_PS_DIR Used by the postscript driver to locate external prologue files. Depending on the build process, gnuplot contains either a builtin copy of those files or simply a default hardcoded path. Use this variable to test the postscript terminal with custom prologue files. See "help postscript prologue".
gnuplotrc When gnuplot is run, it first looks for a system-wide initialization file named gnuplotrc.  The standard location of this file expected by the program is reported by the "show loadpath" command.
.gnuplot After loading the system-wide initialization file, if any, Gnuplot looks for a private initialization file in the HOME directory.  It may contain any legal gnuplot commands, but typically they are limited to setting the preferred terminal and line types and defining frequently-used functions or variables.
fit.log The default name of the logfile output by the "fit" command.
Original authors: Thomas Williams and Colin Kelley.  Starting with gnuplot version 3.8, the project source is cooperatively maintained on SourceForge by a large number of contributors.
Please report bugs using the project bug tracker on SourceForge.
See the printed manual or the on-line help for details on specific commands.  Project web site at http://gnuplot.info
MKINITCPIO(8)                   mkinitcpio manual                  MKINITCPIO(8)
mkinitcpio - Create an initial ramdisk environment
mkinitcpio [options]
Creates an initial ramdisk environment for booting the linux kernel. The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root filesystems and root filesystems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.
-A, --addhooks hooks Add the additional hooks to the image. These will be processed in order after all other hooks from the config file. Multiple hooks should be comma-separated. This option can be specified multiple times.
-c, --config config Use config file to generate the ramdisk. Default: /etc/mkinitcpio.conf.
-d, --generatedir directory Set directory as the location where the initramfs is built. This might be useful to generate a shutdown ramfs in /run/initramfs.
-D, --hookdir directory Set directory as the location where hooks will be searched for when generating the image.
-g, --generate filename Generate a CPIO image as filename. Default: no; this means nothing will be written to the filesystem unless this option is specified.
-H, --hookhelp hookname Output help for hookname hookname.
-h, --help Output a short overview of available command-line switches.
-k, --kernel kernelversion Use kernelversion, instead of the current running kernel. This may be a path to a kernel image (only supported for x86-based architectures), a specific kernel version or the special keyword none. In the latter case, no kernel modules are added to the image.
-L, --listhooks List all available hooks.
-M, --automods Display modules found via autodetection. mkinitcpio will automatically try to determine which kernel modules are needed to start your computer. This option lists which modules were detected.
-n, --nocolor Disable color output.
-U, --uefi filename Generate a UEFI executable as filename. If a CPIO image is successfully built, it will be used to generate a UEFI executable stub image for UEFI booting. This combines the initramfs, the kernel, any specified microcode and the kernel cmdline into one executable. This is useful for boot chain integrity where the file is signed. Default: no. For a list of relevant options see Options for UEFI executable below.
-P, --allpresets Process all presets contained in /etc/mkinitcpio.d. See the -p option for more detail about presets.
-p, --preset preset Build initramfs image(s) according to specified preset. This may be a file in /etc/mkinitcpio.d (without the .preset extension) or a full, absolute path to a file. This option may be specified multiple times to process multiple presets.
-r, --moduleroot root Specifies the root directory to find modules in, defaulting to /.
-S, --skiphooks hooks Skip hooks when generating the image. Multiple hooks should be comma-separated. This option can be specified multiple times.
-s, --save Saves the build directory for the initial ramdisk. Default: no; This means the directory will not be retained if this option isn’t specified. Useful for debugging purposes.
-t, --builddir tmpdir Use tmpdir as the temporary build directory instead of /tmp.  tmpdir must exist. The TMPDIR environment variable is also honored to set this location, but the command line option will take precedence.
-v, --verbose Verbose output. Outputs more information about what’s happening during creation of the ramdisk.
-z, --compress compress Override the compression method with the compress program.
--cmdline filename Use kernel command line with UEFI executable. If none is specified, try one of the files /etc/kernel/cmdline, /usr/share/kernel/cmdline or /proc/cmdline.
--splash filename UEFI executables can show a bitmap file on boot.
--uefistub filename UEFI stub image used for UEFI executable generation. Default: Attempts to look for a systemd-boot or gummiboot stub loader.
--kernelimage filename Include a kernel image for the UEFI executable. Default: one of /lib/modules/$KERNELVERSION/vmlinuz, /boot/vmlinuz-$KERNELVERSION, or /boot/vmlinuz-linux.
--microcode filename Include microcode into the UEFI executable. Default: no.
--osrelease filename Include a os-release file for the UEFI executable. Default: /etc/os-release or /usr/lib/os-release.
A preset is a pre-defined definition on how to create an initial ramdisk. Instead of specifying the configuration file and which output file, every time you generate a new initial ramdisk, you define a preset and use the -p switch to generate an initial ramdisk according to your preset. Presets are located in /etc/mkinitcpio.d
Install hooks are bash scripts which are sourced during mkinitcpio runtime in order to add modules, binaries, and other files to the image. A variety of functions exist to facilitate this.
add_module modname Adds the module specified by modname to the image. Dependencies are derived and added automatically.
add_binary binary [ destination ] [ mode ] Adds a binary to the image. The argument binary need not be an absolute path and, if needed, a lookup will be performed. If the binary is a dynamically linked ELF binary, dependencies will be automatically added. Optionally, a destination within the initramfs image as well as a file mode can be specified. By default, the destintation and mode be taken from the source derived from binary.
add_file path [ destination ] [ mode ] Adds a file and any needed parent directories to the image. Optionally, a destination within the initramfs image as well as a file mode can be specified. By default, the destination and mode will be taken from the source and mode of the file specified by the path.
add_dir path Adds a directory and its parents to the image.
add_full_dir directory [ glob ] [ strip_prefix ] Recursively adds a directory to the image by walking the given path and calling add_file, add_dir, and add_symlink accordingly. This function will not follow symlinks, nor will it add the targets of symlinks.
If the 'glob' argument is passed, only files and symlinks matching this glob will be added.
If the 'strip_prefix' argument is passed, it will be used to strip the destination path (path in the initramfs image) from the prefix specified by the 'strip_prefix' argument. This can be useful when writing rootfs-overlay hooks.
add_symlink path [ link-target ] Adds a symlink to the image at the specified path, optionally pointing to the specified link-target. If the link-target is not provided, it is assumed that this symlink exists in the real filesystem, and the target will be read using readlink. There is no checking done to ensure that the target of the symlink exists, and symlinks will not be followed recursively.
add_all_modules [ -f filter ] pattern Adds modules to the image, without regard for the autodetect whitelist.  pattern should be a subdirectory within the kernel tree describing a subset of modules to be included. Further refinement can be provided via the -f flag with an extended regular expression.
add_checked_modules [ -f filter ] pattern Similar to add_all_modules with the constraint that only modules matching the whitelist generated by the autodetect hook will be added to the image. If the autodetect hook is not present in the image, this function is identical to add_all_modules.
add_runscript Adds a runtime hook to the image, which is a busybox ash compatible shell script. The name of the script is guaranteed to match the name of the hook the script is called from.
Runtime hooks added to the image via the add_runscript function from an install hook are able to provide extra functionality during early userspace. Specific functions in these files will run at different times. A hook can define one or more of these. At each hook point, hooks are run in the order that they are defined in the HOOKS variable, except for cleanup hooks which are run in reverse.
run_earlyhook Functions of this name will be run once the API mounts have been setup and the kernel command line has been parsed. Daemons needed for early userspace should be started from this hook point.
run_hook Functions of this name will be run after any early hooks, and after user defined modules have been installed. This is the most common hook point, and functionality such as scanning for LVM volumes and mapping encrypted volumes should be performed here.
run_latehook Functions of this name will be run after root has been mounted. This is generally used for further necessary setup in the real root, such as mounting other system partitions.
run_cleanuphook Functions of this name are run as late as possible. Any daemons started from a run_earlyhook function should be shut down here in preparation for switching to the real root.
mkinitcpio gives special treatment to certain environment variables passed on the kernel command line:
break[=<premount|postmount>] If specified, mkinitcpio will start a shell during early init. The optional parameter controls when this occurs: when premount or no parameter are specified, the shell will be launched prior to mounting root. If postmount is specified, the shell will be launched after mounting root.
disablehooks=hooklist This is a comma separated list of hooks which will be skipped during early init.
earlymodules=modulelist This is a comma separated list of modules which will be loaded prior to any others. This is generally not needed, and usually points to a configuration or kernel problem.
quiet Causes mkinitcpio to output fewer messages during boot. Errors will not be suppressed.
ro Specifies that root should be mounted with readonly permissions. This is the default behavior.
rw Specifies that root should be mounted with readwrite permissions. This is generally only useful if your initramfs uses the fsck hook.
root=rootdevice This variable describes the root partition which early init will mount before passing control to the real init. mkinitcpio understands a variety of formats, the most basic of which is the path to the block device, either directly such as /dev/sda2, or using a udev symlink such as /dev/disk/by-label/CorsairF80-root. Support for identification by LABEL or UUID tags are also supported, such as, LABEL=CorsairF80-root. As of util-linux 2.22, PARTUUID and PARTLABEL are also supported. Identification via hex encoded major/minor device ID is supported for legacy reasons, but should be avoided as it tends to be fragile.
rootdelay=seconds Sets the delay, in seconds, that mkinitcpio is willing to wait for the root device to show up, if it is not available immediately. This defaults to 10 seconds. If an invalid integer is passed, this variable will have no effect.
rootflags=flaglist A comma-separated list of flags which will be passed onto the mount(8) command when mounting the root filesystem. Acceptable values are filesystem specific.
rootfstype=fstype Overrides the type of filesystem being mounted as root. This should almost never be needed as mount(8) usually detects this on its own.
rd.debug Enables shell debug (xtrace). If rd.log is not also a parameter on the kernel command line, this parameter implies rd.log=console.
rd.log[=<console|file|kmsg|all>] Enables logging of early userspace messages. If specified, the optional parameter describes where this information is logged. Multiple options can be OR’d together using the pipe (|) character. Messages are always logged to the console unless the quiet parameter is passed. If the optional parameter is not specified, kmsg|console is assumed. If rd.log is not present on the kernel command line, no logging will take place.
console Writes output to /dev/console.
file Writes output to /run/initramfs/init.log.
kmsg Writes output to the /dev/kmsg device (introduced in Linux 3.5). This option is a no-op if your kernel lacks support for /dev/kmsg.
all Writes output to all known log targets.
These are only the variables that the core of mkinitcpio honor. Additional hooks may look for other environment variables and should be documented by the help output for the hook.
mkinitcpio aims to create reproducible initramfs images by default.
This means that two subsequent runs of mkinitcpio should produce two files that are identical at the binary level.
Timestamps within the initramfs are set to the Unix epoch of 1970-01-01.
Note that in order for the build to be fully reproducible, the compressor specified (e.g. gzip, xz) must also produce reproducible archives. At the time of writing, as an inexhaustive example, the lzop compressor is incapable of producing reproducible archives due to the insertion of a runtime timestamp.
More information can be found at https://reproducible-builds.org.
/etc/mkinitcpio.conf Default configuration file for mkinitcpio.
/etc/mkinitcpio.d Directory containing mkinitcpio presets.
/etc/initcpio/install, /usr/lib/initcpio/install Search path for build time hooks.
/etc/initcpio/hooks, /usr/lib/initcpio/hooks Search path for early userspace runtime hooks.
mkinitcpio Perform a dry-run. This will generate an initial ramdisk but will not write anything. Use -g to create the real image.
mkinitcpio -p linux Create an initial ramdisk based on the linux preset.
mkinitcpio -g /boot/initramfs-linux.img -k /boot/vmlinuz-linux Create an initial ramdisk for the kernel at /boot/vmlinuz-linux. The resulting image will be written to /boot/initramfs-linux.img.
mkinitcpio -U /efi/EFI/Linux/systemd-linux.efi Create an initial ramdisk for the kernel along with a UEFI executable. The resuling executable will be written to /efi/EFI/Linux/systemd-linux.efi.
mkinitcpio -U /efi/EFI/Linux/systemd-linux.efi --microcode /boot/intel-ucode.img --splash /usr/share/systemd/bootctl/splash-arch.bmp Create an initial ramdisk for the kernel and an UEFI executable. This also includes the Intel CPU microcode and a splash image which will be used during boot.
A more thorough article on configuring mkinitcpio: http://wiki.archlinux.org/index.php/Mkinitcpio
initrd(4), lsinitcpio(1), mkinitcpio.conf(5), bootparam(7)
Upon writing this manpage, there were no noticeable bugs present. Please visit http://bugs.archlinux.org/ for an up to date list.
mkinitcpio is created and maintained by the Arch Linux Developer community.
Copyright (c) Arch Linux 2006-2021
EDITLINE(3)               BSD Library Functions Manual               EDITLINE(3)
editline, el_init, el_end, el_reset, el_gets, el_getc, el_push, el_parse, el_set, el_get, el_source, el_resize, el_line, el_insertstr, el_deletestr, history_init, history_end, history, tok_init, tok_end, tok_reset, tok_line, tok_str — line editor, history and tokenization functions
Command Line Editor Library (libedit, -ledit)
#include <histedit.h>
EditLine * el_init(const char *prog, FILE *fin, FILE *fout, FILE *ferr);
void el_end(EditLine *e);
void el_reset(EditLine *e);
const char * el_gets(EditLine *e, int *count);
int el_getc(EditLine *e, char *ch);
void el_push(EditLine *e, const char *str);
int el_parse(EditLine *e, int argc, const char *argv[]);
int el_set(EditLine *e, int op, ...);
int el_get(EditLine *e, int op, ...);
int el_source(EditLine *e, const char *file);
void el_resize(EditLine *e);
const LineInfo * el_line(EditLine *e);
int el_insertstr(EditLine *e, const char *str);
void el_deletestr(EditLine *e, int count);
History * history_init();
void history_end(History *h);
int history(History *h, HistEvent *ev, int op, ...);
Tokenizer * tok_init(const char *IFS);
void tok_end(Tokenizer *t);
void tok_reset(Tokenizer *t);
int tok_line(Tokenizer *t, const LineInfo *li, int *argc, const char **argv[], int *cursorc, int *cursoro);
int tok_str(Tokenizer *t, const char *str, int *argc, const char **argv[]);
The editline library provides generic line editing, history and tokenization functions, similar to those found in sh(1).
These functions are available in the libedit library (which needs the libtermcap library).  Programs should be linked with -ledit -ltermcap.
The line editing functions use a common data structure, EditLine, which is created by el_init() and freed by el_end().
The following functions are available:
el_init() Initialise the line editor, and return a data structure to be used by all other line editing functions.  prog is the name of the invoking program, used when reading the editrc(5) file to determine which settings to use.  fin, fout and ferr are the input, output, and error streams (respectively) to use.  In this documentation, references to “the tty” are actually to this input/output stream combination.
el_end() Clean up and finish with e, assumed to have been created with el_init().
el_reset() Reset the tty and the parser.  This should be called after an error which may have upset the tty's state.
el_gets() Read a line from the tty.  count is modified to contain the number of characters read.  Returns the line read if successful, or NULL if no characters were read or if an error occurred.
el_getc() Read a character from the tty.  ch is modified to contain the character read.  Returns the number of characters read if successful, -1 otherwise.
el_push() Pushes str back onto the input stream.  This is used by the macro expansion mechanism.  Refer to the description of bind -s in editrc(5) for more information.
el_parse() Parses the argv array (which is argc elements in size) to execute builtin editline commands.  If the command is prefixed with “prog”: then el_parse() will only execute the command if “prog” matches the prog argument supplied to el_init().  The return value is -1 if the command is unknown, 0 if there was no error or “prog” didn't match, or 1 if the command returned an error.  Refer to editrc(5) for more information.
el_set() Set editline parameters.  op determines which parameter to set, and each operation has its own parameter list.
The following values for op are supported, along with the required argument list:
EL_PROMPT, char *(*f)(EditLine *) Define prompt printing function as f, which is to return a string that contains the prompt.
EL_REFRESH Re-display the current line on the next terminal line.
EL_RPROMPT, char *(*f)(EditLine *) Define right side prompt printing function as f, which is to return a string that contains the prompt.
EL_TERMINAL, const char *type Define terminal type of the tty to be type, or to TERM if type is NULL.
EL_EDITOR, const char *mode Set editing mode to mode, which must be one of “emacs” or “vi”.
EL_SIGNAL, int flag If flag is non-zero, editline will install its own signal handler for the following signals when reading command input: SIGCONT, SIGHUP, SIGINT, SIGQUIT, SIGSTOP, SIGTERM, SIGTSTP, and SIGWINCH.  Otherwise, the current signal handlers will be used.
EL_BIND, const char *, ..., NULL Perform the bind builtin command.  Refer to editrc(5) for more information.
EL_ECHOTC, const char *, ..., NULL Perform the echotc builtin command.  Refer to editrc(5) for more information.
EL_SETTC, const char *, ..., NULL Perform the settc builtin command.  Refer to editrc(5) for more information.
EL_SETTY, const char *, ..., NULL Perform the setty builtin command.  Refer to editrc(5) for more information.
EL_TELLTC, const char *, ..., NULL Perform the telltc builtin command.  Refer to editrc(5) for more information.
EL_ADDFN, const char *name, const char *help, unsigned char (*func)(EditLine *e, int ch) Add a user defined function, func(), referred to as name which is invoked when a key which is bound to name is entered.  help is a description of name.  At invocation time, ch is the key which caused the invocation.  The return value of func() should be one of:
CC_NORM       Add a normal character.
CC_NEWLINE    End of line was entered.
CC_EOF        EOF was entered.
CC_ARGHACK    Expecting further command input as arguments, do nothing visually.
CC_REFRESH    Refresh display.
CC_REFRESH_BEEP Refresh display, and beep.
CC_CURSOR     Cursor moved, so update and perform CC_REFRESH.
CC_REDISPLAY  Redisplay entire input line.  This is useful if a key binding outputs extra information.
CC_ERROR      An error occurred.  Beep, and flush tty.
CC_FATAL      Fatal error, reset tty to known state.
EL_HIST, History *(*func)(History *, int op, ...), const char *ptr Defines which history function to use, which is usually history().  ptr should be the value returned by history_init().
EL_EDITMODE, int flag If flag is non-zero, editing is enabled (the default).  Note that this is only an indication, and does not affect the operation of editline.  At this time, it is the caller's responsibility to check this (using el_get()) to determine if editing should be enabled or not.
EL_GETCFN, int (*f)(EditLine *, char *c) Define the character reading function as f, which is to return the number of characters read and store them in c.  This function is called internally by el_gets() and el_getc().  The builtin function can be set or restored with the special function name ``EL_BUILTIN_GETCFN''.
EL_CLIENTDATA, void *data Register data to be associated with this EditLine structure. It can be retrieved with the corresponding el_get() call.
EL_SETFP, int fd, FILE *fp Set the current editline file pointer for “input” fd = 0, “output” fd = 1, or “error” fd = 2 from fp.
el_get() Get editline parameters.  op determines which parameter to retrieve into result.  Returns 0 if successful, -1 otherwise.
The following values for op are supported, along with actual type of result:
EL_PROMPT, char *(*f)(EditLine *) Return a pointer to the function that displays the prompt.
EL_RPROMPT, char *(*f)(EditLine *) Return a pointer to the function that displays the rightside prompt.
EL_EDITOR, const char * Return the name of the editor, which will be one of “emacs” or “vi”.
EL_GETTC, const char *name, void *value Return non-zero if name is a valid termcap(5) capability and set value to the current value of that capability.
EL_SIGNAL, int * Return non-zero if editline has installed private signal handlers (see el_get() above).
EL_EDITMODE, int * Return non-zero if editing is enabled.
EL_GETCFN, int (**f)(EditLine *, char *) Return a pointer to the function that read characters, which is equal to ``EL_BUILTIN_GETCFN'' in the case of the default builtin function.
EL_CLIENTDATA, void **data Retrieve data previously registered with the corresponding el_set() call.
EL_UNBUFFERED, int Sets or clears unbuffered mode.  In this mode, el_gets() will return immediately after processing a single character.
EL_PREP_TERM, int Sets or clears terminal editing mode.
EL_GETFP, int fd, FILE **fp Return in fp the current editline file pointer for “input” fd = 0, “output” fd = 1, or “error” fd = 2.
el_source() Initialise editline by reading the contents of file.  el_parse() is called for each line in file.  If file is NULL, try $PWD/.editrc then $HOME/.editrc.  Refer to editrc(5) for details on the format of file.
el_resize() Must be called if the terminal size changes.  If EL_SIGNAL has been set with el_set(), then this is done automatically.  Otherwise, it's the responsibility of the application to call el_resize() on the appropriate occasions.
el_line() Return the editing information for the current line in a LineInfo structure, which is defined as follows:
typedef struct lineinfo { const char *buffer;    /* address of buffer */ const char *cursor;    /* address of cursor */ const char *lastchar;  /* address of last character */ } LineInfo;
buffer is not NUL terminated.  This function may be called after el_gets() to obtain the LineInfo structure pertaining to line returned by that function, and from within user defined functions added with EL_ADDFN.
el_insertstr() Insert str into the line at the cursor.  Returns -1 if str is empty or won't fit, and 0 otherwise.
el_deletestr() Delete count characters before the cursor.
The history functions use a common data structure, History, which is created by history_init() and freed by history_end().
history_init() Initialise the history list, and return a data structure to be used by all other history list functions.
history_end() Clean up and finish with h, assumed to have been created with history_init().
history() Perform operation op on the history list, with optional arguments as needed by the operation.  ev is changed accordingly to operation. The following values for op are supported, along with the required argument list:
H_SETSIZE, int size Set size of history to size elements.
H_GETSIZE Get number of events currently in history.
H_END Cleans up and finishes with h, assumed to be created with history_init().
H_CLEAR Clear the history.
H_FUNC, void *ptr, history_gfun_t first, history_gfun_t next, history_gfun_t last, history_gfun_t prev, history_gfun_t curr, history_sfun_t set, history_vfun_t clear, history_efun_t enter, history_efun_t add Define functions to perform various history operations.  ptr is the argument given to a function when it's invoked.
H_FIRST Return the first element in the history.
H_LAST Return the last element in the history.
H_PREV Return the previous element in the history.
H_NEXT Return the next element in the history.
H_CURR Return the current element in the history.
H_SET Set the cursor to point to the requested element.
H_ADD, const char *str Append str to the current element of the history, or perform the H_ENTER operation with argument str if there is no current element.
H_APPEND, const char *str Append str to the last new element of the history.