neulab/tldr huggingface dataset:
Warning Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.
The structural integrity check verifies if internal filesystem objects or data structures satisfy the constraints, point to the right objects or are correctly connected together.
There are several cross checks that can detect wrong reference counts of shared extents, backreferences, missing extents of inodes, directory and inode connectivity etc.
The amount of memory required can be high, depending on the size of the filesystem, similarly the run time. Check the modes that can also affect that.
-b|--backup use the first valid set of backup roots stored in the superblock
This can be combined with --super if some of the superblocks are damaged.
--check-data-csum verify checksums of data blocks
This expects that the filesystem is otherwise OK, and is basically an offline scrub that does not repair data from spare copies.
--chunk-root <bytenr> use the given offset bytenr for the chunk tree root
-E|--subvol-extents <subvolid> show extent state for the given subvolume
-p|--progress indicate progress at various checking phases
-Q|--qgroup-report verify qgroup accounting and compare against filesystem accounting
-r|--tree-root <bytenr> use the given offset bytenr for the tree root
--readonly (default) run in read-only mode, this option exists to calm potential panic when users are going to run the checker
-s|--super <superblock> use 'superblock’th superblock copy, valid values are 0, 1 or 2 if the respective superblock offset is within the device size
This can be used to use a different starting point if some of the primary superblock is damaged.
--clear-space-cache v1|v2 completely wipe all free space cache of given type
For free space cache v1, the clear_cache kernel mount option only rebuilds the free space cache for block groups that are modified while the filesystem is mounted with that option. Thus, using this option with v1 makes it possible to actually clear the entire free space cache.
For free space cache v2, the clear_cache kernel mount option destroys the entire free space cache. This option, with v2 provides an alternative method of clearing the free space cache that doesn’t require mounting the filesystem.
--clear-ino-cache remove leftover items pertaining to the deprecated inode map feature
--repair enable the repair mode and attempt to fix problems where possible
Note there’s a warning and 10 second delay when this option is run without --force to give users a chance to think twice before running repair, the warnings in documentation have shown to be insufficient
--init-csum-tree create a new checksum tree and recalculate checksums in all files
Note Do not blindly use this option to fix checksum mismatch problems.
--init-extent-tree build the extent tree from scratch
Note Do not use unless you know what you’re doing.
--mode <MODE> select mode of operation regarding memory and IO
The MODE can be one of:
original The metadata are read into memory and verified, thus the requirements are high on large filesystems and can even lead to out-of-memory conditions. The possible workaround is to export the block device over network to a machine with enough memory.
lowmem This mode is supposed to address the high memory consumption at the cost of increased IO when it needs to re-read blocks. This may increase run time.
Note lowmem mode does not work with --repair yet, and is still considered experimental.
--force allow work on a mounted filesystem. Note that this should work fine on a quiescent or read-only mounted filesystem but may crash if the device is changed externally, eg. by the kernel module. Repair without mount checks is not supported right now.
This option also skips the delay and warning in the repair mode (see --repair).
btrfs check returns a zero exit status if it succeeds. Non zero is returned in case of failure.
mkfs.btrfs(8), btrfs-scrub(8), btrfs-rescue(8)
BEANSTALKD(1)                                                      BEANSTALKD(1)
beanstalkd - simple, fast work queue
beanstalkd [options]
Beanstalkd is a simple work-queue service. Its interface is generic, though it was originally designed for reducing the latency of page views in high-volume web applications by running time-consuming tasks asynchronously.
When started, beanstalkd opens a socket (or uses a file descriptor provided by the init(1) system, see #ENVIRONMENT) and listens for incoming connections. For each connection, it reads a sequence of commands to create, reserve, delete, and otherwise manipulate "jobs", units of work to be done. See file doc/protocol.txt in the beanstalkd distribution for a thorough description of the meaning and format of the beanstalkd protocol.
-b path Use a binlog to keep jobs on persistent storage in directory path. Upon startup, beanstalkd will recover any binlog that is present in path, then, during normal operation, append new jobs and changes in state to the binlog.
-f ms  Call fsync(2) at most once every ms milliseconds. Larger values for ms reduce disk activity and improve speed at the cost of safety. A power failure could result in the loss of up to ms milliseconds of history.
A ms value of 0 will cause beanstalkd to call fsync every time it writes to the binlog.
The default behavior is to sync every 50 ms.
(This option has no effect without -b.)
-F     Never call fsync(2). Equivalent to -f with an infinite ms value.
-h     Show a brief help message and exit.
-l addr Listen on address addr (default is 0.0.0.0).
When addr starts with "unix:", the unprefixed value of it will be used as the local filesystem path to create a UNIX socket instead of a TCP socket. In this case the value of -p will be ignored.
(Option -l has no effect if sd-daemon(5) socket activation is being used. See also #ENVIRONMENT.)
-p port Listen on TCP port port (default is 11300).
(Option -p has no effect if sd-daemon(5) socket activation is being used. See also #ENVIRONMENT.)
-s bytes The size in bytes of each binlog file.
-u user Become the user user and its primary group.
-V     Increase verbosity. May be used more than once to produce more verbose output. The output format is subject to change.
-v     Print the version string and exit.
-z bytes The maximum size in bytes of a job.
-c     This flag has no effect. It is kept for historical compatibility only.
-n     This flag has no effect. It is kept for historical compatibility only.
LISTEN_PID, LISTEN_FDS These variables can be set by init(1). See sd_listen_fds(3) for details.
sd-daemon(3), sd_listen_fds(3)
Files README.md and doc/protocol.txt in the beanstalkd distribution.
https://beanstalkd.github.io/
Beanstalkd is written by Keith Rarick and maintained by the community at https://github.com/beanstalkd/beanstalkd/issues
mmcli(8)                          User Commands                         mmcli(8)
--list-bearers List packet data bearers that are available for the given modem.
--delete-bearer=PATH Delete bearer from a given modem. This option explicitly uses a PATH to define the bearer, you can not use an INDEX to be deleted.
--set-bands=[BAND1|BAND2|...] Set bands to be used for a given modem. These are frequency ranges the modem should use. There are quite a number of supported bands and listing them all here would be quite extensive. For details, see the MMModemBand documentation.
--simple-status Display the status of the given modem.
--location-get-3gpp Show 3GPP based location information (MCC, MNC, LAC, CI).
--location-get-gps-nmea Show GPS based location with NMEA trace information.
--location-get-gps-raw Show GPS based location information with raw values (e.g. latitude, longitude).
--location-get-cdma-bs Show 3GPP2 based location information (location of the CDMA base station).
--location-enable-gps-unmanaged Enable location discovery using GPS but without taking control of the NMEA tty port.
--messaging-delete-sms=PATH Delete an SMS from a given modem. PATH indicates the SMS path.
Send the PIN to the SIM card You'll need first to know which the proper path/index is for the SIM in your modem: $ mmcli -m 0 | grep SIM SIM | path: '/org/freedesktop/ModemManager1/SIM/0'
And after that, you can just use the SIM index: $ mmcli -i 0 --pin=1234 successfully sent PIN code to the SIM
Simple connect and disconnect You can launch the simple connection process like: $ mmcli -m 0 --simple-connect="pin=1234,apn=internet" successfully connected the modem
Then, you can disconnect it like: $ mmcli -m 0 --simple-disconnect successfully disconnected all bearers in the modem
3GPP network scan Scanning for 3GPP networks may really take a long time, so a specific timeout must be given: $ mmcli -m 0 --3gpp-scan --timeout=300
Found 4 networks: 21404 - Yoigo (umts, available) 21407 - Movistar (umts, current) 21401 - vodafone ES (umts, forbidden) 21403 - Orange (umts, forbidden)
$ mmcli -m 0 --messaging-create-sms="text='Hello world',number='+1234567890'" Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/21 (unknown)
$ sudo mmcli -s 21 SMS '/org/freedesktop/ModemManager1/SMS/21' ----------------------------------- Content    |              number: '+1234567890' |                text: 'Hello world' ----------------------------------- Properties |            PDU type: 'submit' |               state: 'stored' |                smsc: 'unknown' |            validity: '0' |               class: '0' |             storage: 'sm' |     delivery report: 'not requested' |   message reference: '0'
$ sudo mmcli -m 0 --messaging-status /org/freedesktop/ModemManager1/Modem/0 ---------------------------- Messaging | supported storages: 'sm, me' |    default storage: 'me'
Sending SMS messages from files As you can see below, the important part is the --messaging-create-sms-with-data and the PATH provided.
$> sudo mmcli -m 0 --messaging-list-sms Found 1 SMS messages: /org/freedesktop/ModemManager1/SMS/0 (received)
$ mmcli -m 0 --location-status /org/freedesktop/ModemManager1/Modem/0 ---------------------------- Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea' |      enabled: 'none' |      signals: 'no'
$ mmcli -m 0 --location-status /org/freedesktop/ModemManager1/Modem/0 ---------------------------- Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea' |      enabled: '3gpp-lac-ci' |      signals: 'no'
GPS location technology enabling We can enable the RAW and NMEA GPS location sources using:
$ mmcli -m 0 --location-status /org/freedesktop/ModemManager1/Modem/0 ---------------------------- Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea' |      enabled: '3gpp-lac-ci, gps-raw, gps-nmea' |      signals: 'no'
GPS location retrieval You can query location source specific information with --location-get-3gpp, --location-get-gps-nmea and --location-get-gps-raw; but also for all at the same time:
$ sudo mmcli -m 0 --location-get /org/freedesktop/ModemManager1/Modem/0 ------------------------- 3GPP location   | Mobile country code: '214' | Mobile network code: '3' |  Location area code: '21071' |             Cell ID: '7033737' ------------------------- GPS NMEA traces | $GPGGA,,,,,,0,,,,,,,,*66 | $GPRMC,,V,,,,,,,,,,N*53 | $GPGSA,A,1,,,,,,,,,,,,,,,*1E | $GPGSV,4,1,16,24,,,,29,,,,05,,,,18,,,*7A | $GPGSV,4,2,16,22,,,,14,,,,11,,,,17,,,*7B | $GPGSV,4,3,16,03,,,,12,,,,30,,,,13,,,*78 | $GPGSV,4,4,16,23,,,,15,,,,27,,,,07,,,*79 | $GPVTG,,T,,M,,N,,K,N*2C ------------------------- Raw GPS         | Not available ------------------------- CDMA BS         | Not available
An example of RAW GPS location information:
$ sudo mmcli -m 0 --location-get-gps-raw /org/freedesktop/ModemManager1/Modem/0 ------------------------- Raw GPS         |  UTC time: '155142.2' | Longitude: '-3.513941' |  Latitude: '40.502603' |  Altitude: '18.000000'
Martyn Russell <martyn@lanedo.com>
GIT-CAT-FILE(1)                    Git Manual                    GIT-CAT-FILE(1)
git-cat-file - Provide content or type and size information for repository objects
git cat-file (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object> git cat-file (--batch[=<format>] | --batch-check[=<format>]) [ --textconv | --filters ] [--follow-symlinks]
In its first form, the command provides the content or the type of an object in the repository. The type is required unless -t or -p is used to find the object type, or -s is used to find the object size, or --textconv or --filters is used (which imply type "blob").
In the second form, a list of objects (separated by linefeeds) is provided on stdin, and the SHA-1, type, and size of each object is printed on stdout. The output format can be overridden using the optional <format> argument. If either --textconv or --filters was specified, the input is expected to list the object names followed by the path name, separated by a single whitespace, so that the appropriate drivers can be determined.
<object> The name of the object to show. For a more complete list of ways to spell object names, see the "SPECIFYING REVISIONS" section in gitrevisions(7).
-t Instead of the content, show the object type identified by <object>.
-s Instead of the content, show the object size identified by <object>.
-e Exit with zero status if <object> exists and is a valid object. If <object> is of an invalid format exit with non-zero and emits an error on stderr.
-p Pretty-print the contents of <object> based on its type.
<type> Typically this matches the real type of <object> but asking for a type that can trivially be dereferenced from the given <object> is also permitted. An example is to ask for a "tree" with <object> being a commit object that contains it, or to ask for a "blob" with <object> being a tag object that points at it.
--textconv Show the content as transformed by a textconv filter. In this case, <object> has to be of the form <tree-ish>:<path>, or :<path> in order to apply the filter to the content recorded in the index at <path>.
--filters Show the content as converted by the filters configured in the current working tree for the given <path> (i.e. smudge filters, end-of-line conversion, etc). In this case, <object> has to be of the form <tree-ish>:<path>, or :<path>.
--path=<path> For use with --textconv or --filters, to allow specifying an object name and a path separately, e.g. when it is difficult to figure out the revision from which the blob came.
--batch, --batch=<format> Print object information and contents for each object provided on stdin. May not be combined with any other options or arguments except --textconv or --filters, in which case the input lines also need to specify the path, separated by whitespace. See the section BATCH OUTPUT below for details.
--batch-check, --batch-check=<format> Print object information for each object provided on stdin. May not be combined with any other options or arguments except --textconv or --filters, in which case the input lines also need to specify the path, separated by whitespace. See the section BATCH OUTPUT below for details.
--batch-all-objects Instead of reading a list of objects on stdin, perform the requested batch operation on all objects in the repository and any alternate object stores (not just reachable objects). Requires --batch or --batch-check be specified. By default, the objects are visited in order sorted by their hashes; see also --unordered below. Objects are presented as-is, without respecting the "replace" mechanism of git- replace(1).
--buffer Normally batch output is flushed after each object is output, so that a process can interactively read and write from cat-file. With this option, the output uses normal stdio buffering; this is much more efficient when invoking --batch-check on a large number of objects.
--unordered When --batch-all-objects is in use, visit objects in an order which may be more efficient for accessing the object contents than hash order. The exact details of the order are unspecified, but if you do not require a specific order, this should generally result in faster output, especially with --batch. Note that cat-file will still show each object only once, even if it is stored multiple times in the repository.
--allow-unknown-type Allow -s or -t to query broken/corrupt objects of unknown type.
--follow-symlinks With --batch or --batch-check, follow symlinks inside the repository when requesting objects with extended SHA-1 expressions of the form tree-ish:path-in-tree. Instead of providing output about the link itself, provide output about the linked-to object. If a symlink points outside the tree-ish (e.g. a link to /foo or a root-level link to ../foo), the portion of the link which is outside the tree will be printed.
This option does not (currently) work correctly when an object in the index is specified (e.g.  :link instead of HEAD:link) rather than one in the tree.
This option cannot (currently) be used unless --batch or --batch-check is used.
For example, consider a git repository containing:
f: a file containing "hello\n" link: a symlink to f dir/link: a symlink to ../f plink: a symlink to ../f alink: a symlink to /etc/passwd
For a regular file f, echo HEAD:f | git cat-file --batch would print
ce013625030ba8dba906f756967f9e9ca394464a blob 6
And echo HEAD:link | git cat-file --batch --follow-symlinks would print the same thing, as would HEAD:dir/link, as they both point at HEAD:f.
Without --follow-symlinks, these would print data about the symlink itself. In the case of HEAD:link, you would see
4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
Both plink and alink point outside the tree, so they would respectively print:
symlink 4 ../f
symlink 11 /etc/passwd
If -t is specified, one of the <type>.
If -s is specified, the size of the <object> in bytes.
If -e is specified, no output, unless the <object> is malformed.
If -p is specified, the contents of <object> are pretty-printed.
If <type> is specified, the raw (though uncompressed) contents of the <object> will be returned.
If --batch or --batch-check is given, cat-file will read objects from stdin, one per line, and print information about them. By default, the whole line is considered as an object, as if it were fed to git-rev- parse(1).
You can specify the information shown for each object by using a custom <format>. The <format> is copied literally to stdout for each object, with placeholders of the form %(atom) expanded, followed by a newline. The available atoms are:
objectname The full hex representation of the object name.
objecttype The type of the object (the same as cat-file -t reports).
objectsize The size, in bytes, of the object (the same as cat-file -s reports).
objectsize:disk The size, in bytes, that the object takes up on disk. See the note about on-disk sizes in the CAVEATS section below.
deltabase If the object is stored as a delta on-disk, this expands to the full hex representation of the delta base object name. Otherwise, expands to the null OID (all zeroes). See CAVEATS below.
rest If this atom is used in the output string, input lines are split at the first whitespace boundary. All characters before that whitespace are considered to be the object name; characters after that first run of whitespace (i.e., the "rest" of the line) are output in place of the %(rest) atom.
If no format is specified, the default format is %(objectname) %(objecttype) %(objectsize).
If --batch is specified, the object information is followed by the object contents (consisting of %(objectsize) bytes), followed by a newline.
For example, --batch without a custom format would produce:
<oid> SP <type> SP <size> LF <contents> LF
Whereas --batch-check='%(objectname) %(objecttype)' would produce:
<oid> SP <type> LF
If a name is specified on stdin that cannot be resolved to an object in the repository, then cat-file will ignore any custom format and print:
<object> SP missing LF
If a name is specified that might refer to more than one object (an ambiguous short sha), then cat-file will ignore any custom format and print:
<object> SP ambiguous LF
If --follow-symlinks is used, and a symlink in the repository points outside the repository, then cat-file will ignore any custom format and print:
symlink SP <size> LF <symlink> LF
The symlink will either be absolute (beginning with a /), or relative to the tree root. For instance, if dir/link points to ../../foo, then <symlink> will be ../foo. <size> is the size of the symlink in bytes.
If --follow-symlinks is used, the following error messages will be displayed:
is printed when the initial symlink requested does not exist.
dangling SP <size> LF <object> LF
is printed when the initial symlink exists, but something that it (transitive-of) points to does not.
loop SP <size> LF <object> LF
is printed for symlink loops (or any symlinks that require more than 40 link resolutions to resolve).
notdir SP <size> LF <object> LF
is printed when, during symlink resolution, a file is used as a directory name.
Note that the sizes of objects on disk are reported accurately, but care should be taken in drawing conclusions about which refs or objects are responsible for disk usage. The size of a packed non-delta object may be much larger than the size of objects which delta against it, but the choice of which object is the base and which is the delta is arbitrary and is subject to change during a repack.
Note also that multiple copies of an object may be present in the object database; in this case, it is undefined which copyâ€™s size or delta base will be reported.
podman(1)()                                                          podman(1)()
podman - Simple management tool for pods, containers and images
podman [options] command
Podman (Pod Manager) is a fully featured container engine that is a simple daemonless tool.  Podman provides a Docker-CLI comparable command line that eases the transition from other container engines and allows the management of pods, containers and images.  Simply put: alias docker=podman.  Most Podman commands can be run as a regular user, without requiring additional privileges.
Podman uses Buildah(1) internally to create container images. Both tools share image (not container) storage, hence each can use or manipulate images (but not containers) created by the other.
Default settings for flags are defined in containers.conf. Most settings for Remote connections use the server's containers.conf, except when documented in man pages.
podman [GLOBAL OPTIONS]
--cgroup-manager=manager The CGroup manager to use for container cgroups. Supported values are cgroupfs or systemd. Default is systemd unless overridden in the containers.conf file.
Note: Setting this flag can cause certain commands to break when called on containers previously created by the other CGroup manager type.  Note: CGroup manager is not supported in rootless mode when using CGroups Version V1.
--cni-config-dir Path of the configuration directory for CNI networks.  (Default: /etc/cni/net.d)
--connection, -c Connection to use for remote podman (Default connection is configured in containers.conf) Remote connections use local containers.conf for default.
--conmon Path of the conmon binary (Default path is configured in containers.conf)
--events-backend=type Backend to use for storing events. Allowed values are file, journald, and none. When file is specified, the events are stored under a subdirectory of the tmpdir location (see --tmpdir below).
--help, -h Print usage statement
--hooks-dir=path Each *.json file in the path configures a hook for Podman containers. For more details on the syntax of the JSON files and the semantics of hook injection, see oci-hooks(5).  Podman and libpod currently support both the 1.0.0 and 0.1.0 hook schemas, although the 0.1.0 schema is deprecated.
This option may be set multiple times; paths from later options have higher precedence (oci-hooks(5) discusses directory precedence).
For the annotation conditions, libpod uses any annotations set in the generated OCI configuration.
For the bind-mount conditions, only mounts explicitly requested by the caller via --volume are considered.  Bind mounts that libpod inserts by default (e.g. /dev/shm) are not considered.
If --hooks-dir is unset for root callers, Podman and libpod will currently default to /usr/share/containers/oci/hooks.d and /etc/containers/oci/hooks.d in order of increasing precedence.  Using these defaults is deprecated, and callers should migrate to explicitly setting --hooks-dir.
Podman and libpod currently support an additional precreate state which is called before the runtime's create operation.  Unlike the other stages, which receive the container state on their standard input, precreate hooks receive the proposed runtime configuration on their standard input.  They may alter that configuration as they see fit, and write the altered form to their standard output.
WARNING: the precreate hook lets you do powerful things, such as adding additional mounts to the runtime configuration.  That power also makes it easy to break things.  Before reporting libpod errors, try running your container with precreate hooks disabled to see if the problem is due to one of your hooks.
--identity=path Path to ssh identity file. If the identity file has been encrypted, podman prompts the user for the passphrase.  If no identity file is provided and no user is given, podman defaults to the user running the podman command.  Podman prompts for the login password on the remote server.
Identity value resolution precedence: - command line value - environment variable CONTAINER_SSHKEY, if CONTAINER_HOST is found - containers.conf Remote connections use local containers.conf for default.
--log-level=level Log messages at and above specified level: debug, info, warn, error, fatal or panic (default: "warn")
--namespace=namespace Set libpod namespace. Namespaces are used to separate groups of containers and pods in libpod's state.  When namespace is set, created containers and pods will join the given namespace, and only containers and pods in the given namespace will be visible to Podman.
--network-cmd-path=path Path to the command binary to use for setting up a network.  It is currently only used for setting up a slirp4netns network.  If "" is used then the binary is looked up using the $PATH environment variable.
--remote, -r Access Podman service will be remote Remote connections use local containers.conf for default.
--url=value URL to access Podman service (default from containers.conf, rootless unix://run/user/$UID/podman/podman.sock or as root unix://run/podman/podman.sock).
• CONTAINER_HOST is of the format <schema>://[<user[:<password>]@]<host>[:<port>][<path>]
Details: - user will default to either root or current running user - password has no default - host must be provided and is either the IP or name of the machine hosting the Podman service - port defaults to 22 - path defaults to either /run/podman/podman.sock, or /run/user/<uid>/podman/podman.sock if running rootless.
URL value resolution precedence: - command line value - environment variable CONTAINER_HOST - containers.conf - unix://run/podman/podman.sock Remote connections use local containers.conf for default.
--root=value Storage root dir in which data, including images, is stored (default: "/var/lib/containers/storage" for UID 0, "$HOME/.local/share/containers/storage" for other users).  Default root dir configured in /etc/containers/storage.conf.
Overriding this option will cause the storage-opt settings in /etc/containers/storage.conf to be ignored.  The user must specify additional options via the --storage-opt flag.
--runroot=value Storage state directory where all state information is stored (default: "/run/containers/storage" for UID 0, "/run/user/$UID/run" for other users).  Default state dir configured in /etc/containers/storage.conf.
--runtime=value Name of the OCI runtime as specified in containers.conf or absolute path to the OCI compatible binary used to run containers.
--runtime-flag=flag Adds global flags for the container runtime. To list the supported flags, please consult the manpages of the selected container runtime (runc is the default runtime, the manpage to consult is runc(8).  When the machine is configured for cgroup V2, the default runtime is crun, the manpage to consult is crun(8).).
Note: Do not pass the leading -- to the flag. To pass the runc flag --log-format json to podman build, the option given would be --runtime- flag log-format=json.
--storage-driver=value Storage driver.  The default storage driver for UID 0 is configured in /etc/containers/storage.conf ($HOME/.config/containers/storage.conf in rootless mode), and is vfs for non-root users when fuse-overlayfs is not available.  The STORAGE_DRIVER environment variable overrides the default.  The --storage-driver specified driver overrides all.
--storage-opt=value Storage driver option, Default storage driver options are configured in /etc/containers/storage.conf ($HOME/.config/containers/storage.conf in rootless mode). The STORAGE_OPTS environment variable overrides the default. The --storage-opt specified options overrides all. If you specify --storage-opt="", no storage options will be used.
--syslog=true|false Output logging information to syslog as well as the console (default false).
On remote clients, logging is directed to the file $HOME/.config/containers/podman.log.
--tmpdir Path to the tmp directory, for libpod runtime content.
NOTE --tmpdir is not used for the temporary storage of downloaded images. Use the environment variable TMPDIR to change the temporary storage location of downloaded container images. Podman defaults to use /var/tmp.
--version, -v Print the version
Environment Variables Podman can set up environment variables from env of [engine] table in containers.conf. These variables can be overridden by passing environment variables before the podman commands.
Remote Access The Podman command can be used with remote services using the --remote flag. Connections can be made using local unix domain sockets, ssh or directly to tcp sockets. When specifying the podman --remote flag, only the global options --url, --identity, --log-level, --connection are used.
Connection information can also be managed using the containers.conf file.
Exit Codes The exit code from podman gives information about why the container failed to run or why it exited.  When podman commands exit with a non- zero code, the exit codes follow the chroot standard, see below:
125 The error is with podman itself
$ podman run --foo busybox; echo $? Error: unknown flag: --foo 125
126 Executing a contained command and the command cannot be invoked
$ podman run busybox /etc; echo $? Error: container_linux.go:346: starting container process caused "exec: \"/etc\": permission denied": OCI runtime error 126
127 Executing a contained command and the command cannot be found $ podman run busybox foo; echo $? Error: container_linux.go:346: starting container process caused "exec: \"foo\": executable file not found in $PATH": OCI runtime error 127
Exit code contained command exit code
$ podman run busybox /bin/sh -c 'exit 3'; echo $? 3
containers.conf (/usr/share/containers/containers.conf, /etc/containers/containers.conf, $HOME/.config/containers/containers.conf)
Podman has builtin defaults for command line options. These defaults can be overridden using the containers.conf configuration files.
Distributions ship the /usr/share/containers/containers.conf file with their default settings. Administrators can override fields in this file by creating the /etc/containers/containers.conf file.  Users can further modify defaults by creating the $HOME/.config/containers/containers.conf file. Podman merges its builtin defaults with the specified fields from these files, if they exist. Fields specified in the users file override the administrator's file, which overrides the distribution's file, which override the built-in defaults.
Podman uses builtin defaults if no containers.conf file is found.
If the CONTAINERS_CONF environment variable is set, then its value is used for the containers.conf file rather than the default.
mounts.conf (/usr/share/containers/mounts.conf)
The mounts.conf file specifies volume mount directories that are automatically mounted inside containers when executing the podman run or podman start commands. Administrators can override the defaults file by creating /etc/containers/mounts.conf.
When Podman runs in rootless mode, the file $HOME/.config/containers/mounts.conf will override the default if it exists. Please refer to containers-mounts.conf(5) for further details.
policy.json (/etc/containers/policy.json)
Signature verification policy files are used to specify policy, e.g. trusted keys, applicable when deciding whether to accept an image, or individual signatures of that image, as valid.
registries.conf (/etc/containers/registries.conf, $HOME/.config/containers/registries.conf)
registries.conf is the configuration file which specifies which container registries should be consulted when completing image names which do not include a registry or domain portion.
Non root users of Podman can create the $HOME/.config/containers/registries.conf file to be used instead of the system defaults.
If the CONTAINERS_REGISTRIES_CONF environment variable is set, then its value is used for the registries.conf file rather than the default.
storage.conf (/etc/containers/storage.conf, $HOME/.config/containers/storage.conf)
storage.conf is the storage configuration file for all tools using containers/storage
The storage configuration file specifies all of the available container storage options for tools using shared container storage.
When Podman runs in rootless mode, the file $HOME/.config/containers/storage.conf is used instead of the system defaults.
If the CONTAINERS_STORAGE_CONF environment variable is set, the its value is used for the storage.conf file rather than the default.
Rootless mode Podman can also be used as non-root user. When podman runs in rootless mode, a user namespace is automatically created for the user, defined in /etc/subuid and /etc/subgid.
Containers created by a non-root user are not visible to other users and are not seen or managed by Podman running as root.
It is required to have multiple uids/gids set for a user.  Be sure the user is present in the files /etc/subuid and /etc/subgid.
If you have a recent version of usermod, you can execute the following commands to add the ranges to the files
$ sudo usermod --add-subuids 10000-75535 USERNAME $ sudo usermod --add-subgids 10000-75535 USERNAME
Or just add the content manually.
$ echo USERNAME:10000:65536 >> /etc/subuid $ echo USERNAME:10000:65536 >> /etc/subgid
See the subuid(5) and subgid(5) man pages for more information.
Images are pulled under XDG_DATA_HOME when specified, otherwise in the home directory of the user under .local/share/containers/storage.
Currently the slirp4netns package is required to be installed to create a network device, otherwise rootless containers need to run in the network namespace of the host.
In certain environments like HPC (High Performance Computing), users cannot take advantage of the additional UIDs and GIDs from the /etc/subuid and /etc/subgid systems.  However, in this environment, rootless Podman can operate with a single UID.  To make this work, set the ignore_chown_errors option in the /etc/containers/storage.conf or in ~/.config/containers/storage.conf files. This option tells Podman when pulling an image to ignore chown errors when attempting to change a file in a container image to match the non-root UID in the image. This means all files get saved as the user's UID. Note this could cause issues when running the container.
NOTE: Unsupported file systems in rootless mode The Overlay file system (OverlayFS) is not supported with kernels prior to 5.12.9 in rootless mode.  The fuse-overlayfs package is a tool that provides the functionality of OverlayFS in user namespace that allows mounting file systems in rootless environments.  It is recommended to install the fuse-overlayfs package.  In rootless mode, Podman will automatically use the fuse-overlayfs program as the mount_program if installed, as long as the $HOME/.config/containers/storage.conf file was not previously created.  If storage.conf exists in the homedir, add mount_program = "/usr/bin/fuse-overlayfs" under [storage.options.overlay] to enable this feature.
The Network File System (NFS) and other distributed file systems (for example: Lustre, Spectrum Scale, the General Parallel File System (GPFS)) are not supported when running in rootless mode as these file systems do not understand user namespace.  However, rootless Podman can make use of an NFS Homedir by modifying the $HOME/.config/containers/storage.conf to have the graphroot option point to a directory stored on local (Non NFS) storage.
For more information, please refer to the Podman Troubleshooting Page.
containers-mounts.conf(5), containers-registries.conf(5), containers- storage.conf(5), buildah(1), containers.conf(5), oci-hooks(5), containers-policy.json(5), crun(8), runc(8), subuid(5), subgid(5), slirp4netns(1), conmon(8).
Dec 2016, Originally compiled by Dan Walsh dwalsh@redhat.com ⟨mailto:dwalsh@redhat.com⟩
RAW(8)                        System Administration                       RAW(8)
raw - bind a Linux raw character device
raw /dev/raw/raw<N> <major> <minor>
raw /dev/raw/raw<N> /dev/<blockdev>
raw -q /dev/raw/raw<N>
raw -qa
raw is used to bind a Linux raw character device to a block device. Any block device may be used: at the time of binding, the device driver does not even have to be accessible (it may be loaded on demand as a kernel module later).
raw is used in two modes: it either sets raw device bindings, or it queries existing bindings. When setting a raw device, /dev/raw/raw<N> is the device name of an existing raw device node in the filesystem. The block device to which it is to be bound can be specified either in terms of its major and minor device numbers, or as a path name /dev/<blockdev> to an existing block device file.
The bindings already in existence can be queried with the -q option, which is used either with a raw device filename to query that one device, or with the -a option to query all bound raw devices.
Unbinding can be done by specifying major and minor 0.
Once bound to a block device, a raw device can be opened, read and written, just like the block device it is bound to. However, the raw device does not behave exactly like the block device. In particular, access to the raw device bypasses the kernel’s block buffer cache entirely: all I/O is done directly to and from the address space of the process performing the I/O. If the underlying block device driver can support DMA, then no data copying at all is required to complete the I/O.
Because raw I/O involves direct hardware access to a process’s memory, a few extra restrictions must be observed. All I/Os must be correctly aligned in memory and on disk: they must start at a sector offset on disk, they must be an exact number of sectors long, and the data buffer in virtual memory must also be aligned to a multiple of the sector size. The sector size is 512 bytes for most devices.
-q, --query Set query mode. raw will query an existing binding instead of setting a new one.
-a, --all With -q, specify that all bound raw devices should be queried.
Rather than using raw devices applications should prefer open2 devices, such as /dev/sda1, with the O_DIRECT flag.
The Linux dd(1) command should be used without the bs= option, or the blocksize needs to be a multiple of the sector size of the device (512 bytes usually), otherwise it will fail with "Invalid Argument" messages (EINVAL).
Raw I/O devices do not maintain cache coherency with the Linux block device buffer cache. If you use raw I/O to overwrite data already in the buffer cache, the buffer cache will no longer correspond to the contents of the actual storage device underneath. This is deliberate, but is regarded as either a bug or a feature, depending on who you ask!
Stephen Tweedie <sct@redhat.com>
The raw command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
NTFSFIX(8)                   System Manager's Manual                  NTFSFIX(8)
ntfsfix - fix common errors and force Windows to check NTFS
ntfsfix [options] device
ntfsfix is a utility that fixes some common NTFS problems.  ntfsfix is NOT a Linux version of chkdsk.  It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.
You may run ntfsfix on an NTFS volume if you think it was damaged by Windows or some other way and it cannot be mounted.
Below is a summary of all the options that ntfsfix accepts.  Nearly all options have two equivalent names.  The short name is preceded by - and the long name is preceded by --.  Any single letter options, that don't take an argument, can be combined into a single command, e.g.  -fv is equivalent to -f -v.  Long named options can be abbreviated to any unique prefix of their name.
-b, --clear-bad-sectors Clear the list of bad sectors. This is useful after cloning an old disk with bad sectors to a new disk.
-d, --clear-dirty Clear the volume dirty flag if the volume can be fixed and mounted.  If the option is not present or the volume cannot be fixed, the dirty volume flag is set to request a volume checking at next mount.
-h, --help Show a list of options with a brief description of each one.
-n, --no-action Do not write anything, just show what would have been done.
-V, --version Show the version number, copyright and license
There are no known problems with ntfsfix.  If you find a bug please send an email describing the problem to the development team: ntfs-3g-devel@lists.sf.net
ntfsfix was written by Anton Altaparmakov, with contributions from Szabolcs Szakacsits.  It was ported to ntfs-3g by Erik Larsson and Jean- Pierre Andre.
ntfsfix is part of the ntfs-3g package and is available from: http://www.tuxera.com/community/
mkntfs(8), ntfsprogs(8)
NEWSBOAT(1)                                                          NEWSBOAT(1)
newsboat - an RSS/Atom feed reader for text terminals
newsboat [-r] [-e] [-i opmlfile] [-u urlfile] [-c cachefile] [-C configfile] [-X] [-o] [-x <command> ...] [-h]
Newsboat is an RSS/Atom feed reader for text terminals. RSS and Atom are a number of widely-used XML formats to transmit, publish and syndicate articles, for example news or blog articles. Newsboat is designed to be used on text terminals on Unix or Unix-like systems such as GNU/Linux, BSD or macOS.
-h, --help Display help
-r, --refresh-on-start Refresh feeds on start
-e, --export-to-opml Export feeds as OPML to stdout
-X, --vacuum Compact the cache by: 1) reclaiming the space that was left empty when data was deleted; and 2) defragmenting the entries in the cache. This doesn’t delete the entries; for that, see cleanup-on-quit, delete-read-articles-on-quit, keep-articles-days, and max-items settings.
--cleanup Remove unreferenced entries from the cache and quit Newsboat. Feeds and their articles will be removed if the feedurl is no longer in the urls file.
Additionally, if the delete-read-articles-on-quit configuration is set, all read articles will be deleted (including articles of feeds which are still in the urls file).
-v, -V, --version Get version information about Newsboat and the libraries it uses
-i opmlfile, --import-from-opml=opmlfile Import an OPML file
-u urlfile, --url-file=urlfile Use an alternative URL file
-c cachefile, --cache-file=cachefile Use an alternative cache file
-C configfile, --config-file=configfile Use an alternative configuration file
-x command ..., --execute=command... Execute one or more commands to run Newsboat unattended. Currently available commands are "reload" and "print-unread".
-l loglevel, --log-level=loglevel Generate a logfile with a certain loglevel. Valid loglevels are 1 to 6. An actual logfile will only be written when you provide a logfile name.
-d logfile, --log-file=logfile Use this logfile as output when logging debug messages. Please note that this only works when providing a loglevel.
-E file, --export-to-file=file Export a list of read articles (resp. their GUIDs). This can be used to transfer information about read articles between different computers.
-I file, --import-from-file=file Import a list of read articles and mark them as read if they are held in the cache. This is to be used in conjunction with the -E commandline parameter.
After you’ve installed Newsboat, you can run it for the first time by typing newsboat on your command prompt. This will bring you the following message:
Error: no URLs configured. Please fill the file /home/ak/.newsboat/urls with RSS feed URLs or import an OPML file.
Newsboat 2.22 usage: ./newsboat [-i <file>|-e] [-u <urlfile>] [-c <cachefile>] [-x <command> ...] [-h] -e, --export-to-opml            export OPML feed to stdout -r, --refresh-on-start          refresh feeds on start -i, --import-from-opml=<file>   import OPML file -u, --url-file=<urlfile>        read RSS feed URLs from <urlfile> -c, --cache-file=<cachefile>    use <cachefile> as cache file -C, --config-file=<configfile>  read configuration from <configfile> -X, --vacuum                    compact the cache -x, --execute=<command>... execute list of commands -q, --quiet                     quiet startup -v, --version                   get version information -l, --log-level=<loglevel>      write a log with a certain loglevel (valid values: 1 to 6) -d, --log-file=<logfile>        use <logfile> as output log file -E, --export-to-file=<file>     export list of read articles to <file> -I, --import-from-file=<file>   import list of read articles from <file> -h, --help                      this help --cleanup                   remove unreferenced items from cache
This means that Newsboat can’t start without any configured feeds. To add feeds to Newsboat, you can either add URLs to the configuration file ~/.newsboat/urls or you can import an OPML file by running newsboat -i blogroll.opml. To manually add URLs, open the file with your favorite text editor and add the URLs, one per line:
http://rss.cnn.com/rss/cnn_topstories.rss http://newsrss.bbc.co.uk/rss/newsonline_world_edition/front_page/rss.xml
If you need to add URLs that have restricted access via username/password, simply provide the username/password in the following way:
https://username:password@hostname.domain.tld/feed.rss
In order to protect username and password, make sure that ~/.newsboat/urls is only readable by you and, optionally, your group:
$ chmod u=rw,g=r,o= ~/.newsboat/urls
Newsboat also makes sure that usernames and passwords within URLs aren’t displayed in its user interface. In case there is a @ in the username, you need to write it as %40 instead so that it can be distinguished from the @ that separates the username/password part from the hostname part.
You can also configure local files as feeds, by prefixing the local path with file:// and adding it to the urls file:
file:///var/log/rss_eventlog.xml
The urls file can also contain comments: lines that start with # can contain anything you want. Comments are ignored by Newsboat, but can serve as documentation for you. Please note, that commenting out URLs for debugging purposes might lead to unexpected data loss, see the cleanup-on-quit setting below for details.
Now you can run Newsboat again, and it will present you with a controllable list of the URLs that you configured previously. You can now start downloading the feeds, either by pressing "R" to download all feeds, or by pressing "r" to download the currently selected feed. You can then select a feed you want to read, and by pressing "Enter", you can go to the article list for this feed. This works even while the downloading is still in progress.
You can now see the list of available articles by their title. A "N" on the left indicates that an article wasn’t read yet. Pressing "Enter" brings you to the content of the article. You can scroll through this text, and also run a browser (default: lynx) to view the complete article if the content is empty or just an abstract or a short description. Each URL in the article has a number next to it; to open it, type # and then the number, then press "Enter". For single-digit links, like 3, you can just press that number on the keyboard.
Pressing "q" brings you back to the article list, and pressing "q" again brings you back to the feed list. Pressing "q" a third time then closes Newsboat.