bmon

package: bmon

title: bmon(8)

summary: bandwidth monitor and rate estimator

text:
# bmon(8)

## NAME
bmon - bandwidth monitor and rate estimator

## SYNOPSIS
bmon [--show-all] [--use-si] [--input=MODULE] [--output=MODULE] [OPTIONS...]

## DESCRIPTION
bmon is a monitoring and debugging tool to capture networking related statistics and prepare them visually in a human friendly way. It features various output methods including an interactive curses user interface and a programmable text output for scripting.

## OPTIONS
-h, --help

Prints a short help text and exits.

-V, --version

Prints the versioning identifier and exits.

-i, --input=MODULE[:OPTIONS][,MODULE...]

Set list of input modules to load and use. Multiple modules can be used in parallel. bmon automatically loads a useful and working input module by default. See INPUT MODULES for more details.

-o, --outputMODULE[:OPTIONS][,MODULE...]

Set list of output modules to load and use. Multiple modules can be used in parallel. By default, bmon will use the curses output mode, if that is not available due to an incompatible console it will fall back to a simple text mode. See OUTPUT MODULES for more details.

-U, --use-si

Use SI unit system (1KB = 1'000 bytes) instead of 1KB = 1'024 bytes.

-f, --configfile=FILE

Set alternative path to configuration file.

-p, --policy=POLICY

Set policy defining which network interfaces to display. See INTERFACE SELECTION for more details.

-a, --show-all=

Display all interfaces, even interface that are administratively down.

-r, --read-interval=FLOAT

Set interval in seconds in which input modules read statistics from their source. The default is 1.0 seconds.

-R, --rate-interval=FLOAT

Set interval in seconds in which the rate per counter is calculated. The default is 1.0 seconds.

-b, --use-bit

Show rates in bits per second instead of bytes per second.

-L, --lifetime=FLOAT

Set lifetime of an element in seconds before it is no longer displayed without receiving any statistical updates. The default is 30 seconds.

## INPUT MODULES
Input modules provide statistical data about elements. Each element consists of attributes which represents a counter, a rate, or a percentage. Elements may carry additional child elements to represent a hierarchy. Each element is assigned to a group defined by the input module. Input modules are polled in the frequence of the configured read interval.

The following input modules are available:

netlink

Uses the Netlink protocol to collect interface and traffic control statistics from the kernel. This is the default input module.

proc

Reads interface statistics from the /proc/net/dev file. This is considered a legacy interface and provided for backwards compatibily reasons. This is a fallback module if the Netlink interface is not available.

dummy

Programmable input module for debugging and testing purposes.

null

No data collected.

To receive additional information about a module, run the module with the "help" option set like this:

bmon -i netlink:help

See MODULE CONFIGURATION for more details.

## OUTPUT MODULES
Output modules display or export the statistical data collected by input modules. Multiple output modules can be run at the same time. bmon will not prevent possible conflicts such as multiple output modules writing to the console.

The following output modules exist:

curses

Interactive curses based text user interface providing real time rate estimations and a graphical representatio nof each attribute. Press '?' to display the quick reference guide. This is the default output mode.

ascii

Simple programmable text output intended for human consumption. Capable of printing list of interfaces, detailed counters and graphs to the console. This is the default fallback output mode if curses is not available.

format

Fully scriptable output mode inteded for consumption by other programs. See the module help text for additional information.

null

Disable output.

To receive additional information about a module, run the module with the "help" option set like this:

bmon -o curses:help

See MODULE CONFIGURATION for more details.

## MODULE CONFIGURATION
The syntax to configure modules is as follows:

ARGUMENT ::= mod1[:OPTS][,mod2[:OPTS]...]

OPTS ::= OPTION[;OPTION...]

OPTION ::= option[=value]

Run the module with option "help" to receive the list of options for each module:

bmon -i module:help

## INTERFACE SELECTION
The following syntax is used to define the interface selection policy:

SELECTION ::= NAME[,NAME[,...]]

NAME ::= [!]interface

The interface name may contain the character '*' which will act as a wildcard and represents any number of any character type, e.g. eth*, h*0, ...

Examples:

lo,eth0,eth1

eth*,!eth0

## EXAMPLES
To run bmon in curses mode monitoring the interfaces eth0 and eth1:

bmon -p eth0,eth1 -o curses

To run bmon in format mode, monitoring any eth* interfaces, with a specified format string:

bmon -p 'eth*' -o format:fmt='$(element:name) $(attr:rxrate:packets)\n'

## FILES
/etc/bmon.conf

$HOME/.bmonrc

## SEE ALSO
ip(8), netstat(8), ifconfig(8), netlink(7),

## AUTHOR
Thomas Graf <tgraf@suug.ch> among others


boa

package: boa

title: boa(8)

text:
# boa(8)

## NAME
boa - a single-tasking high performance http server

## SYNOPSIS
boa [-c server_root] [-r chroot] [-d]

## DESCRIPTION
Boa is a single-tasking HTTP server. That means that unlike traditional web servers, it does not fork for each incoming connection, nor does it fork many copies of itself to handle multiple connections. It internally multiplexes all of the ongoing HTTP connections, and forks only for CGI programs (which must be separate processes.) Preliminary tests show Boa is more than twice as fast as Apache.

The primary design goals of Boa are speed and security. Security, in the sense of "can't be subverted by a malicious user", not "fine grained access control and encrypted communications". Boa is not intended as a feature-packed server; if you want one of those, check out WN from John Franks. Modifications to Boa that improve its speed, security, robustness, and portability, are eagerly sought. Other features may be added if they can be achieved without hurting the primary goals.

## OPTIONS
-d

instruct Boa not to fork itself (non-daemonize).

-c server_root

choose a server root overriding the default SERVER_ROOT #define in defines.h The server root must hold your local copy of the configuration file

-r chroot

instruct Boa where to chdir and chroot to. The chdir/chroot is done before the configuration file is read, or any log files are opened.

## FILES
boa.conf - the sole configuration file for Boa.

The directives in this file are defined in the DIRECTIVES section.

mime.types - the

MimeTypes <filename> defines what Content-Type Boa will send in an HTTP/1.0 or better transaction.

## DIRECTIVES
The Boa configuration file is parsed with a lex/yacc or flex/bison generated parser. If it reports an error, the line number will be provided; it should be easy to spot. The syntax of each of these rules is very simple, and they can occur in any order. Where possible, these directives mimic those of NCSA httpd 1.3; We saw no reason to introduce gratuitous differences.

Note: the "ServerRoot" is not in this configuration file. It can be compiled into the server (see defines.h ) or specified on the command line with the -c option.

The following directives are contained in the boa.conf file, and most, but not all, are required.

Port <integer>

This is the port that Boa runs on. The default port for http servers is 80. If it is less than 1024, the server must be started as root.

User <user name or UID>

The name or UID the server should run as. For Boa to attempt this, the server must be started as root.

Group <group name or GID>

The group name or GID the server should run as. For Boa to attempt this, the server must be started as root.

ServerAdmin <email address>

The email address where server problems should be sent. Note: this is not currently used.

PidFile <filename>

Where to put the pid of the process. Comment out to write no pid file. Note: Because Boa drops privileges at startup, and the pid file is written by the UID/GID before doing so, Boa does not attempt removal of the pid file.

ErrorLog <filename>

The location of the error log file. If this does not start with /, it is considered relative to the server root. Set to /dev/null if you don't want errors logged.

AccessLog <filename>

The location of the access log file. If this does not start with /, it is considered relative to the server root. Comment out or set to /dev/null (less effective) to disable access logging.

VerboseCGILogs

This is a logical switch and does not take any parameters. Comment out to disable.

CGILog <filename>

The location of the CGI error log file. If this does not start with /, it is considered relative to the server root. If specified, this is the file that the stderr of CGIs is tied to, *instead* of to the ErrorLog.

CGIumask <umask>

The CGIumask is set immediately before execution of the CGI. The default value is 027. The number must be interpretable unambiguously by the C function strtol. No base is specified, so one may use a hexadecimal, decimal, or octal number if it is prefixed accordingly.

ServerName <server_name>

The name of this server that should be sent back to clients if different than that returned by gethostname.

VirtualHost

This is a logical switch and does not take any parameters. Comment out to disable. Given DocumentRoot /var/www, requests on interface 'A' or IP 'IP-A' become /var/www/IP-A. Example: http://localhost/ becomes /var/www/127.0.0.1

VHostRoot <directory>

The root location for all virtually hosted data Comment out to disable. Incompatible with 'Virtualhost' and 'DocumentRoot'!! Given VHostRoot /var/www, requests to host foo.bar.com, where foo.bar.com is ip a.b.c.d, become /var/www/a.b.c.d/foo.bar.com Hostnames are "cleaned", and must conform to the rules specified in rfc1034, which are be summarized here: Hostnames must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Hostnames must not exceed 63 characters in length.

DefaultVHost <hostname>

Define this in order to have a default hostname when the client does not specify one, if using VirtualHostName. If not specified, the word "default" will be used for compatibility with older clients.

DocumentRoot <directory>

The root directory of the HTML documents. If this does not start with /, it is considered relative to the server root.

UserDir <directory>

The name of the directory which is appended onto a user's home directory if a ~user request is received.

DirectoryIndex <filename>

Name of the file to use as a pre-written HTML directory index. Please make and use these files. On the fly creation of directory indexes can be slow.

DirectoryMaker <directory>

Name of the program used to generate on-the-fly directory listings. The program must take one or two command-line arguments, the first being the directory to index (absolute), and the second, which is optional, contains what Boa would have the "title" of the document be. Comment out if you don't want on the fly directory listings. If this does not start with /, it is considered relative to the server root.

KeepAliveMax <integer>

Number of KeepAlive requests to allow per connection. Comment out, or set to 0 to disable keepalive processing.

KeepAliveTimeout <integer>

Number of seconds to wait before keepalive connections time out.

MimeTypes <file>

The location of the mime.types file. If this does not start with /, it is considered relative to the server root. Set to /dev/null if you do not want to load a mime types file. Do *not* comment out (better use AddType!)

DefaultType <mime type>

MIME type used if the file extension is unknown, or there is no file extension.

AddType <mime type> <extension> [extension...]

Associates a MIME type with an extension or extensions.

Redirect, Alias, and ScriptAlias <path1> <path2>

Redirect, Alias, and ScriptAlias all have the same semantics -- they match the beginning of a request and take appropriate action. Use Redirect for other servers, Alias for the same server, and ScriptAlias to enable directories for script execution. Redirect allows you to tell clients about documents which used to exist in your server's namespace, but do not anymore. This allows you tell the clients where to look for the relocated document.

Alias aliases one path to another. Of course, symbolic links in the file system work fine too.

ScriptAlias maps a virtual path to a directory for serving scripts.

Please see the included boa.conf for defaults and examples.

## HISTORY
Like the Linux kernel, even numbered versions are "stable", and odd numbered versions are "unstable", or rather, "development". Versions 0.91 and 0.91beta of Boa were released by Paul Phillips <paulp@go2net.com>

Version 0.92 was released by Larry Doolittle on December 12, 1996.

Version 0.93 was the development version of 0.94.

Version 0.94 was released 22 Jan 2000.

## BUGS
There are probably bugs, but we are not aware of any at this time.

## AUTHOR
Boa was created by Paul Phillips <paulp@go2net.com>. It is now being maintained and enhanced by Larry Doolittle <ldoolitt@boa.org> and Jon Nelson <jnelson@boa.org>.

Linux is the development platform at the moment, other OS's are known to work. If you'd like to contribute to this effort, contact Larry or Jon via e-mail.

## LICENSE
This program is distributed under the GNU General Public License, as noted in each source file.

branch: sisyphus


boltd

package: bolt

title: boltd(8)

text:
# boltd(8)

## NAME
boltd - thunderbolt device managing system daemon

## SYNOPSIS
boltd [OPTIONS]

## DESCRIPTION
boltd is the thunderbolt device manager daemon. Its goal is to enable the secure and convenient use of thunderbolt devices by using the security features of modern thunderbolt controllers. It provides the org.freedesktop.bolt name on the system bus. boltd is autostarted via systemd/udev if a thunderbolt device is connected.

The thunderbolt I/O technology works by bridging PCIe between the controllers on each end of the connection, which in turn means that devices connected via Thunderbolt are ultimately connected via PCIe. Therefore thunderbolt can achieve very high connection speeds, fast enough to even drive external graphics cards. The downside is that it also makes certain attacks possible. To mitigate these security problems, the latest version — known as Thunderbolt 3 — supports different security levels:

none

No security. The behavior is identical to previous Thunderbolt versions.

dponly

No PCIe tunnels are created at all, but DisplayPort tunnels are allowed and will work.

user

Connected devices must be authorized by the user. Only then will the PCIe tunnels be activated.

secure

Basically the same as user mode, but additionally a key will be written to the device the first time the device is connected. This key will then be used to verify the identity of the connected device.

usbonly

One PCIe tunnel is created to a usb controller in a thunderbolt dock; no other downstream PCIe tunnels are authorized (needs 4.17 kernel and recent hardware).

The primary task of boltd is to authorize thunderbolt peripherals if the security level is either user or secure. It provides a D-Bus API to list devices, enroll them (authorize and store them in the local database) and forget them again (remove previously enrolled devices). It also emits signals if new devices are connected (or removed). During enrollment devices can be set to be automatically authorized as soon as they are connected. A command line tool, called boltctl(1), can be used to control the daemon and perform all the above mentioned tasks.

The pre-boot access control list (BootACL) feature is active when supported by the firmware and when boltd is running on a new enough Linux kernel (>= 4.17). The BootACL is a list of UUIDs, that can be written to the thunderbolt controller. If enabled in the BIOS, all devices in that list will be authorized by the firmware during pre-boot, which means these devices can be used in the BIOS setup and also during Linux early boot. NB: no device verification is done, even when the security level is set to secure mode in the BIOS, i.e. the maximal effective security level for devices in the BootACL is only user. If BootACL support is present, all new devices will be automatically added. Devices that are forgotten (removed from boltd) will also be removed from the BootACL. When a controller is offline, changes to the BootACL will be written to a journal and synchronized back when the controller is online again.

IOMMU support: if the hardware and firmware support using the input–output memory management unit (IOMMU) to restrict direct memory access to certain safe regions, boltd will detect that feature and change its behavior: As long as iommu support is active, as indicated by the iommu_dma_protection sysfs attribute of the domain controller, new devices will be automatically enrolled with the iommu policy and existing devices with iommu (or auto) policy will be automatically authorized by boltd without any user interaction. When iommu is not active, devices that were enrolled with the iommu policy will not be authorized automatically. The status of iommu support can be inspected by using boltctl domains.

## OPTIONS
-h, --help

Prints a short help text and exits.

--version

Shows the version number and exits.

-r, --replace

Replace the currently running boltd instance.

--journal

Force logging to the journal.

-v, --verbose

Print debug output.

## ENVIRONMENT
RUNTIME_DIRECTORY

Specifies the path where the daemon stores data that only has to live as long as the current boot. Will be set automatically when started via systemd (>= 240). If not set the default path for runtime data is /run/boltd.

STATE_DIRECTORY

Specifies the path where the daemon stores device information, including the keys used for authorization. Overwrites the path that was set at compile time. Will be set automatically when started via systemd (>= 240).

BOLT_DBPATH

Same as STATE_DIRECTORY but takes precedence over that, if set.

## EXIT STATUS
On success 0 is returned, a non-zero failure code otherwise.

## AUTHOR
Written by Christian Kellner <ckellner@redhat.com>.

## SEE ALSO
boltctl(1)


bonnie++

package: bonnie++

title: bonnie++(8)

summary: program to test hard drive performance.

text:
# bonnie++(8)

## NAME
bonnie++ - program to test hard drive performance.

## SYNOPSIS
bonnie++ [-d dir] [-c concurrency] [-s size(MiB)[:chunk-size(b)[:seeks[:seekers]]]] [-n number-to-stat(*1024)[:max-size[:min-size][:num-directories[:chunk-size]]]] [-m machine-name] [-r ram-size-in-MiB] [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use] [-q] [-f size-for-char-io] [-b] [-D] [-p processes | -y p|s ] [-z seed-num|-Z random-file]

## DESCRIPTION
This manual page documents briefly the bonnie++, program.

Bonnie++ is a program to test hard drives and file systems for performance or the lack therof. There are a many different types of file system operations which different applications use to different degrees. Bonnie++ tests some of them and for each test gives a result of the amount of work done per second and the percentage of CPU time this took. For performance results higher numbers are better, for CPU usage and latency lower are better (NB a configuration scoring a performance result of 2000 and a CPU result of 90% is better in terms of CPU use than a configuration delivering performance of 1000 and CPU usage of 60%).

There are two sections to the program's operations. The first is to test the IO throughput in a fashion that is designed to simulate some types of database applications. The second is to test creation, reading, and deleting many small files in a fashion similar to the usage patterns of programs such as Squid or INN.

All the details of the tests performed by Bonnie++ are contained in the file /usr/share/doc/bonnie++/readme.html

## OPTIONS
For Bonnie++ every option is of the form of a hyphen followed by a letter and then the next parameter contains the value.

-d

the directory to use for the tests.

-c

the level of concurrency (default 1). The number of copies of the test to be performed at the same time.

-s

the size of the file(s) for IO performance measures in megabytes. If the size is greater than 1G then multiple files will be used to store the data, and each file will be up to 1G in size. This parameter may include the chunk size seperated from the size by a colon. The chunk-size is measured in bytes and must be a power of two from 256 to 1048576, the default is 8192. NB You can specify the size in giga-bytes or the chunk-size in kilo-bytes if you add g or k to the end of the number respectively. This parameter may also include the number of seeks (default 8192) and the number of seeker processes (default 5). If the specified size is 0 then this test will be skipped.

-n

the number of files for the file creation test. This is measured in multiples of 1024 files. This is because no-one will want to test less than 1024 files, and we need the extra space on braille displays. If the specified number is 0 then this test will be skipped.

The default for this test is to test with 0 byte files. To use files of other sizes you can specify number:max:min:num-directories:chunk-size where max is the maximum size and min is the minimum size (both default to 0 if not specified). If minimum and maximum sizes are specified then every file will have a random size from the range min..max inclusive. If you specify a number of directories then the files will be evenly distributed amoung that many sub-directories.

If max is -1 then hard links will be created instead of files. If max is -2 then soft links will be created instead of files.

-m

name of the machine - for display purposes only.

-r

RAM size in megabytes. If you specify this the other parameters will be checked to ensure they make sense for a machine of that much RAM. You should not need to do this in general use as it should be able to discover the RAM size. NB If you specify a size of 0 then all checks will be disabled...

-x

number of test runs. This is useful if you want to perform more than one test. It will dump output continuously in CSV format until either the number of tests have been completed, or it is killed.

-u

user-id to use. When running as root specify the UID to use for the tests. It is not recommended to use root (since the occasion when a Bonnie++ bug wiped out someone's system), so if you really want to run as root then use -u root. Also if you want to specify the group to run as then use the user:group format. If you specify a user by name but no group then the primary group of that user will be chosen. If you specify a user by number and no group then the group will be nogroup.

-g

group-id to use. Same as using :group for the -u parameter, just a different way to specify it for compatibility with other programs.

-q

quiet mode. If specified then some of the extra informational messages will be suppressed. Also the csv data will be the only output on standard out and the plain text data will be on standard error. This means you can run bonnie++ -q >> file.csv to record your csv data.

-f size-for-char-io

fast mode control, skips per-char IO tests if no parameter, otherwise specifies the size of the tests for per-char IO tests (default 20M).

-b

no write buffering. fsync() after every write.

-p

number of processes to serve semaphores for. This is used to create the semaphores for synchronising multiple Bonnie++ processes. All the processes which are told to use the semaphore with -ys will start each test with synchronization. Use "-p -1" to delete the semaphore.

-y s|p

perform synchronization before each test. Option s for semaphores and option p for prompting.

-D

use direct IO (O_DIRECT) for the bulk IO tests

-z seed

random number seed to repeat the same test.

-Z random-file

file containing random data in network byte order.

## MULTIPLE PROCESSES
Run the following commands to run three copies of Bonnie++ simultaneously:

bonnie++ -p3

bonnie++ -y > out1 &

bonnie++ -y > out2 &

bonnie++ -y > out3 &

## OUTPUT
The primary output is plain-text in 80 columns which is designed to fit well when pasted into email and which will work well with Braille displays.

The second type of output is CSV (Comma Seperated Values). This can easily be imported into any spread-sheet or database program. Also I have included the programs bon_csv2html and bon_csv2txt to convert CSV data to HTML and plain-ascii respectively.

The "Name:Size etc" field has the name, filesize, IO chunk size, concurrency, number of seeks, and number of seek processes separated by : characters.

For every test two numbers are reported, the amount of work done (higher numbers are better) and the percentage of CPU time taken to perform the work (lower numbers are better). If a test completes in less than 500ms then the output will be displayed as "++++". This is because such a test result can't be calculated accurately due to rounding errors and I would rather display no result than a wrong result.

Data volumes for the 80 column text display use "K" for KiB (1024 bytes), "M" for MiB (1048576 bytes), and "G" for GiB (1073741824 bytes). So K/sec means a multiple of 1024 bytes per second.

## AUTHOR
This program, its manual page, and the Debian package were written by Russell Coker <russell@coker.com.au>, parts of the program are based on the work of Tim Bray <tbray@textuality.com>.

The documentation, the Perl scripts, and all the code for testing the creation of thousands of files was written by Russell Coker, but the entire package is under joint copyright with Tim Bray.

## SIGNALS
Handles SIGINT and does a cleanup (which may take some time), a second SIGINT or a SIGQUIT will cause it to immediately die.

SIGXCPU and SIGXFSZ act like SIGINT.

Ignores SIGHUP.

## BUGS
The random file sizes will add up to different values for different test runs. I plan to add some code that checks the sum and ensures that the sum of the values will be the same on seperate runs.

## AVAILABILITY
The source is available from http://www.coker.com.au/bonnie++ .

See http://etbe.coker.com.au/category/benchmark for further information.

## SEE ALSO
zcav(8), getc_putc(8), bon_csv2html(1), bon_csv2txt(1)


title: getc_putc(8)

summary: program to test hard drive performance.

text:
# getc_putc(8)

## NAME
getc_putc - program to test hard drive performance.

## SYNOPSIS
getc_putc [-d dir] [-s size(KiB)] [-m machine-name] [-u uid-to-use:gid-to-use] [-g gid-to-use]

## DESCRIPTION
This manual page documents briefly the getc_putc, program.

This is a simple adjunct to the bonnie++ benchmark. It is used to test various ways of doing IO one byte at a time, usually you don't need to do enough of this for it to be a performance issue for it to matter much which way you do it. But sometimes it's necessary (for example whan parsing IO from a terminal and then launching another process which will take over all IO, such as a simple shell).

The real benefits of this are to help settle some arguements about the performance of such things, and to educate novices about how bad per-byte IO really is.

## OPTIONS
For getc_putc every option is of the form of a hyphen followed by a letter and then the next parameter contains the value.

-d

the directory to use for the tests.

-s

the size of the file for byte IO performance measured in kilobytes. NB You can specify the size in mega-bytes if you add 'm' to the end of the number. The default for this test is to test with a 512MiB file. Of the file only 1/64 of it will be used for write() and read() system calls (anything else takes too long).

-m

name of the machine - for display purposes only.

-u

user-id to use. When running as root specify the UID to use for the tests. It is not recommended to use root, so if you really want to run as root then use -u root. Also if you want to specify the group to run as then use the user:group format. If you specify a user by name but no group then the primary group of that user will be chosen. If you specify a user by number and no group then the group will be nogroup.

-g

group-id to use. Same as using :group for the -u parameter, just a different way to specify it for compatibility with other programs.

-q

quiet mode. If specified then some of the extra informational messages will be suppressed. Also the csv data will be the only output on standard out and the plain text data will be on standard error. This means you can run getc_putc -q >> file.csv to record your csv data.

## OUTPUT
The primary output is plain-text in 80 columns which is designed to fit well when pasted into email and which will work well with Braille displays.

The second type of output is CSV (Comma Seperated Values). This can easily be imported into any spread-sheet or database program.

For every test the result is a speed in KiB/s. I do not display the CPU time because it presumably is 99% of the power of a single CPU (or something very close to that).

## AUTHOR
This program, it's manual page, and the Debian package were written by Russell Coker <russell@coker.com.au>.

The documentation, the Perl scripts, and all the code for testing the creation of thousands of files was written by Russell Coker, but the entire package is under joint copyright with Tim Bray.

## SIGNALS
Handles SIGINT and does a cleanup (which may take some time), a second SIGINT or a SIGQUIT will cause it to immidiately die.

SIGXCPU and SIGXFSZ act like SIGINT.

Ignores SIGHUP.

## AVAILABILITY
The source is available from http://www.coker.com.au/bonnie++ .

See http://etbe.coker.com.au/category/benchmark for further information.

## SEE ALSO
bonnie++(8), zcav(8)


zcav

title: zcav(8)

text:
# zcav(8)

## NAME
zcav - program to test raw hard drive throughput.

## SYNOPSIS
zcav [-b block-size[:chunk-size]] [-c count] [-r [first-block]:last-block] [-w] [-s skip-rate] [-u uid-to-use:gid-to-use] [-g gid-to-use] [-l log-file] [-f] file-name [-l log-file [-f] file-name]...

## DESCRIPTION
This manual page documents briefly the zcav, program.

Modern hard drives have a constant rotational speed but have varying numbers of sectors per track (outside tracks are longer and have more sectors). This is referred to as Zoned Constant Angular Velocity (or ZCAV). The outer tracks will have a higher data transfer rate due to having more sectors per track, these tracks generally have the lower track/sector numbers.

This program tests the ZCAV performance of a hard drive, by reading the entire data on it a specified number of times. The file name given as the first parameter, it can be specified as -, for standard input. This file will be opened as read-only and in usual operation it will be /dev/hdX or /dev/ide/host0/busX/targetY/lun0/disc depending on whether you use devfs or not (NB operating systems other than Linux will have different device names).

The output should be able to be easily graphed with gnuplot which is what I use to view the results.

## OPTIONS
-b

the size (in Meg) of the blocks to read/write (default 512M), optionally followed by a ':' and the chunk size for read/write operations (default 1M). Note that the chunk size must be less than or equal to the block size and must also be significantly less than the size of the RAM in the machine. Also note that for the write test there will be a fsync() after writing every chunk.

-c

the number of times to read/write the entire disk.

-r

the range of data (in Meg) to read/write on each pass (default the entire device). Useful if you want to quickly test part of a large drive. If a single number is given then that is the last block to read, if two numbers then it's the start and end of a range. Values are in megs, but they are rounded down to the block size.

-s

skip rate. The option -s 10 will cause it to read every 10th block and skip the rest. Accepts values from 2 to 20.

-f

the file-name for the input data. This isn't needed on well configured systems that have a recent Glibc where you can specify the file name without the -f flag.

-u

user-id to use. When running as root specify the UID to run the tests as, it is not recommended to use root, so if you want to run as root use -u root. Also if you want to specify the group to run as then use the user:group format. If you specify a user by name but no group then the primary group of that user will be chosen. If you specify a user by number and no group then the group will be nogroup.

-g

group-id to use. Same as using :group for the -u parameter, just a different way to specify it for compatibility with other programs.

-w

write zero blocks to the disk instead of reading from the disk - will destroy data!

## AUTHOR
This program, it's manual page, and the Debian package were written by Russell Coker <russell@coker.com.au>.

## AVAILABILITY
The source is available from http://www.coker.com.au/bonnie++ .

See http://etbe.coker.com.au/category/benchmark for further information.


title: boot0cfg(8)

text:
# boot0cfg(8)

## NAME
boot0cfg — boot manager installation/configuration utility

## SYNOPSIS
boot0cfg

[-Bv] [-b boot0] [-d drive] [-e bell character] [-f file] [-i volume-id] [-m mask] [-o options] [-s slice] [-t ticks] disk

## DESCRIPTION
The FreeBSD ‘boot0’ boot manager permits the operator to select from which disk and slice an i386 machine (PC) is booted.

Note that what are referred to here as “slices” are typically called “partitions” in non-BSD documentation relating to the PC. Typically, only non-removable disks are sliced.

The boot0cfg utility optionally installs the ‘boot0’ boot manager on the specified disk; and allows various operational parameters to be configured.

On PCs, a boot manager typically occupies sector 0 of a disk, which is known as the Master Boot Record (MBR). The MBR contains both code (to which control is passed by the PC BIOS) and data (an embedded table of defined slices).

The options are:

-B

Install the ‘boot0’ boot manager. This option causes MBR code to be replaced, without affecting the embedded slice table.

-b boot0

Specify which ‘boot0’ image to use. The default is /usr/share/boot0/boot0lin (this version does not support FAT partitions type in the sake of Linux SWAP, LVM, RAID and LBA extended partition type), /usr/share/boot0/boot0 is the original FreeBSD version, /usr/share/boot0/boot0pxe provides experimental PXE loader code. All theese ‘boot0’ variations will use the video card as output. Alternatively /usr/share/boot0/boot0sio can be used for output to the COM1 port. (Be aware that nothing will be output to the COM1 port unless the modem signals DSR and CTS are active.)

-d drive

Specify the drive number used by the PC BIOS in referencing the drive which contains the specified disk. Typically this will be 0x80 for the first hard drive, 0x81 for the second hard drive, and so on; however any integer between 0 and 0xff is acceptable here.

-e bell character

Set the character to be printed in case of input error.

-f file

Specify that a backup copy of the preexisting MBR should be written to file. This file is created if it does not exist, and replaced if it does.

-i volume-id

Specifies a volume-id (in the form XXXX-XXXX) to be saved at location 0x1b8 in the MBR. This information is sometimes used by NT, XP and Vista to identify the disk drive. The option is only compatible with version 2.00 of the 512-byte boot block.

-m mask

Specify slices to be enabled/disabled, where mask is an integer between 0 (no slices enabled) and 0xf (all four slices enabled). Each mask bit enables corresponding slice if set to 1. The least significant bit of the mask corresponds to slice 1, the most significant bit of the mask corresponds to slice 4.

-o options

A comma-separated string of any of the following options may be specified (with “no” prepended as necessary): packet

Use the disk packet (BIOS INT 0x13 extensions) interface, as opposed to the legacy (CHS) interface, when doing disk I/O. This allows booting above cylinder 1023, but requires specific BIOS support. The default is ‘packet’.

setdrv

Forces the drive containing the disk to be referenced using drive number definable by means of the -d option. The default is ‘nosetdrv’.

update

Allow the MBR to be updated by the boot manager. (The MBR may be updated to flag slices as ‘active’, and to save slice selection information.) This is the default; a ‘noupdate’ option causes the MBR to be treated as read-only.

-s slice

Set the default boot selection to slice. Values between 1 and 4 refer to slices; a value of 5 refers to the option of booting from a second disk. The special string “PXE” or a value of 6 can be used to boot via PXE.

-t ticks

Set the timeout value to ticks. (There are approximately 18.2 ticks per second.)

-v

Verbose: display information about the slices defined, etc.

## FILES
/usr/share/boot0/boot0lin

The default ‘boot0’ image

/usr/share/boot0/boot0

Unmodified FreeBSD ‘boot0’ variant

/usr/share/boot0/boot0pxe

Experimental PXE bootloader

/usr/share/boot0/boot0sio

Image for serial consoles (COM1,9600,8,N,1,MODEM)

## EXIT STATUS
The boot0cfg utility exits 0 on success, and >0 if an error occurs.

## EXAMPLES
To boot slice 2 on the next boot:

boot0cfg -s 2 ad0

To enable just slices 1 and 3 in the menu:

boot0cfg -m 0x5 ad0

To go back to non-interactive booting, use fdisk(8) to install the default MBR:

fdisk -B ad0

## SEE ALSO
geom(4), boot(8), fdisk(8), gpart(8)

## AUTHORS
Robert Nordier ⟨rnordier@FreeBSD.org⟩.

## BUGS
Use of the ‘packet’ option may cause ‘boot0’ to fail, depending on the nature of BIOS support.

Use of the ‘setdrv’ option with an incorrect -d operand may cause the boot0 code to write the MBR to the wrong disk, thus trashing its previous content. Be careful.


bootc

package: bootc

title: bootc(8)

text:
# bootc(8)

bootc - Deploy and transactionally in-place with bootable container images

## SYNOPSIS
bootc [OPTIONS...] <SUBCOMMAND>

## DESCRIPTION
Deploy and transactionally in-place with bootable container images.

The bootc project currently uses ostree-containers as a backend to support a model of bootable container images. Once installed, whether directly via bootc install (executed as part of a container) or via another mechanism such as an OS installer tool, further updates can be pulled and bootc upgrade. <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## SUBCOMMANDS<!-- BEGIN GENERATED SUBCOMMANDS -->
Command

Description

bootc upgrade

Download and queue an updated container image to apply

bootc switch

Target a new container image reference to boot

bootc rollback

Change the bootloader entry ordering; the deployment under rollback will be queued for the next boot, and the current will become rollback. If there is a staged entry (an unapplied, queued upgrade) then it will be discarded

bootc edit

Apply full changes to the host specification

bootc status

Display status

bootc usr-overlay

Add a transient overlayfs on /usr

bootc install

Install the running container to a target

bootc container

Operations which can be executed as part of a container build

bootc loader-entries

Operations on Boot Loader Specification (BLS) entries

bootc composefs-finalize-staged

<!-- END GENERATED SUBCOMMANDS -->

## VERSION
v1.16.4


bootc-composefs-finalize-staged

title: bootc-composefs-finalize-staged(8)

summary: finalize\-staged

text:
# bootc-composefs-finalize-staged(8)

bootc-composefs-finalize-staged - TODO: Add description

## SYNOPSIS
bootc composefs-finalize-staged

## DESCRIPTION
TODO: Add description <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## EXAMPLES
TODO: Add practical examples showing how to use this command.

## SEE ALSO
bootc(8)

## VERSION
v1.16.4


bootc-config-diff

title: bootc-config-diff(8)

summary: diff

text:
# bootc-config-diff(8)

bootc-config-diff - Diff current /etc configuration versus default

## SYNOPSIS
bootc config-diff

## DESCRIPTION
Diff current /etc configuration versus default <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## EXAMPLES
TODO: Add practical examples showing how to use this command.

## SEE ALSO
bootc(8)

## VERSION
v1.16.4


bootc-container

title: bootc-container(8)

text:
# bootc-container(8)

bootc-container - Operations which can be executed as part of a container build

## SYNOPSIS
bootc container [OPTIONS...] <SUBCOMMAND>

## DESCRIPTION
Operations which can be executed as part of a container build <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## SUBCOMMANDS<!-- BEGIN GENERATED SUBCOMMANDS -->
Command

Description

bootc container inspect

Output information about the container image

bootc container lint

Perform relatively inexpensive static analysis checks as part of a container build

bootc container split-kernel-and-rootfs

Split kernel and rootfs from a container image

bootc container ukify

Build a Unified Kernel Image (UKI) using ukify

<!-- END GENERATED SUBCOMMANDS -->

## VERSION
v1.16.4


bootc-container-inspect

title: bootc-container-inspect(8)

text:
# bootc-container-inspect(8)

bootc-container-inspect - Output JSON to stdout containing the container image metadata

## SYNOPSIS
bootc container inspect

## DESCRIPTION
Output JSON to stdout containing the container image metadata.

## OUTPUT
The command outputs a JSON object with the following fields:

- kargs: An array of kernel arguments embedded in the container image.

- kernel: An object containing kernel information (or null if no kernel is found):

- version: The kernel version identifier. For vmlinuz kernels, this is derived from the /usr/lib/modules/<version> directory name (equivalent to uname -r). For UKI images, this is the UKI filename without the .efi extension - which should usually be the same as the uname.

- unified: A boolean indicating whether the kernel is packaged as a UKI (Unified Kernel Image).

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--rootfs=ROOTFS

```
Operate on the provided rootfs
Default: /
```

--json

```
Output in JSON format
```

--format=FORMAT

```
The output format
Possible values:
- humanreadable
- yaml
- json
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Inspect container image metadata:

```
bootc container inspect
```

Example output (vmlinuz kernel):

```
{

  "kargs": [

    "console=ttyS0",

    "quiet"

  ],

  "kernel": {

    "version": "6.12.0-0.rc6.51.fc42.x86_64",

    "unified": false

  }
}
```

Example output (UKI):

```
{

  "kargs": [],

  "kernel": {

    "version": "7e11ac46e3e022053e7226a20104ac656bf72d1a",

    "unified": true

  }
}
```

## SEE ALSO
bootc(8)

## VERSION
v1.16.4


bootc-container-lint

title: bootc-container-lint(8)

text:
# bootc-container-lint(8)

bootc-container-lint - Perform relatively inexpensive static analysis checks as part of a container build

## SYNOPSIS
bootc container lint [OPTIONS...]

## DESCRIPTION
Perform relatively inexpensive static analysis checks as part of a container build.

This is intended to be invoked via e.g. RUN bootc container lint as part of a build process; it will error if any problems are detected.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--rootfs=ROOTFS

```
Operate on the provided rootfs
Default: /
```

--fatal-warnings

```
Make warnings fatal
```

--list

```
Instead of executing the lints, just print all available lints. At the current time, this will output in YAML format because it's reasonably human friendly. However, there is no commitment to maintaining this exact format; do not parse it via code or scripts
```

--skip=SKIP

```
Skip checking the targeted lints, by name. Use `--list` to discover the set of available lints
```

--no-truncate

```
Don't truncate the output. By default, only a limited number of entries are shown for each lint, followed by a count of remaining entries
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-container-split-kernel-and-rootfs

summary: kernel\-and\-rootfs

text:
# bootc-container-split-kernel-and-rootfs(8)

bootc-container-split-kernel-and-rootfs - Split kernel and rootfs from a container image

## SYNOPSIS
bootc container split-kernel-and-rootfs

## DESCRIPTION
Split kernel and rootfs from a container image

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--rootfs=ROOTFS

```
Operate on the provided rootfs
Default: /
```

--output=OUTPUT

```
Output directory for the extracted kernel files
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Extract kernel files from the current root filesystem to /kernel:

```
bootc container split-kernel-and-rootfs --output /kernel
```

This extracts the kernel and initramfs from the current root filesystem (/) and places them in /kernel/<kernel-version>/ with filenames vmlinuz and initramfs.img.

Extract kernel files from a mounted container rootfs:

```
bootc container split-kernel-and-rootfs --rootfs /mnt/container-rootfs --output /output/kernels
```

This extracts kernel files from a container filesystem mounted at /mnt/container-rootfs and places them in the output directory.

Example output structure:

After running the command, the output directory will contain:

```
/output/kernels/
└── 6.5.0-15-generic/

    ├── vmlinuz

    └── initramfs.img
```

where 6.5.0-15-generic is the detected kernel version from the source rootfs.

## SEE ALSO
bootc(8)

## VERSION
v1.16.4


bootc-container-ukify

title: bootc-container-ukify(8)

text:
# bootc-container-ukify(8)

bootc-container-ukify - Build a Unified Kernel Image (UKI) using ukify

## SYNOPSIS
bootc container ukify [OPTIONS] [-- UKIFY_ARGS...]

## DESCRIPTION
Build a Unified Kernel Image (UKI) using ukify

This command computes the necessary arguments from the container image (kernel, initrd, cmdline, os-release) and invokes ukify with them. Any additional arguments after -- are passed through to ukify unchanged.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
ARGS

```
Additional arguments to pass to ukify (after `--`)
```

--rootfs=ROOTFS

```
Operate on the provided rootfs
Default: /
```

--allow-missing-verity

```
Make fs-verity validation optional in case the filesystem doesn't support it
```

--write-dumpfile-to=WRITE_DUMPFILE_TO

```
Write a dumpfile to this path
```

--kernel-dir=KERNEL_DIR

```
The directory containing the kernel and initramfs.img Must be of the format /parent/$kernel_version
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES

```
bootc container ukify --rootfs /target -- --output /output/uki.efi
```

## SEE ALSO
bootc(8), ukify(1)

## VERSION
v1.16.4


bootc-edit

title: bootc-edit(8)

text:
# bootc-edit(8)

bootc-edit - Apply full changes to the host specification

## SYNOPSIS
bootc edit [OPTIONS...]

## DESCRIPTION
Apply full changes to the host specification.

This command operates very similarly to kubectl apply; if invoked interactively, then the current host specification will be presented in the system default \$EDITOR for interactive changes.

It is also possible to directly provide new contents via bootc edit \--filename.

Only changes to the spec section are honored.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
-f, --filename=FILENAME

```
Use filename to edit system specification
```

--quiet

```
Don't display progress
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-install

title: bootc-install(8)

text:
# bootc-install(8)

bootc-install - Install the running container to a target

## SYNOPSIS
bootc install [OPTIONS...] <SUBCOMMAND>

## DESCRIPTION
Install the running container to a target.

## Understanding installations
OCI containers are effectively layers of tarballs with JSON for metadata; they cannot be booted directly. The bootc install flow is a highly opinionated method to take the contents of the container image and install it to a target block device (or an existing filesystem) in such a way that it can be booted.

For example, a Linux partition table and filesystem is used, and the bootloader and kernel embedded in the container image are also prepared.

A bootc installed container currently uses OSTree as a backend, and this sets it up such that a subsequent bootc upgrade can perform in-place updates.

An installation is not simply a copy of the container filesystem, but includes other setup and metadata.

## Secure Boot Keys
When installing with systemd-boot, bootc can let systemd-boot can handle enrollment of Secure Boot keys by putting signed EFI signature lists in /usr/lib/bootc/install/secureboot-keys which will copy over into ESP/loader/keys after bootloader installation. The keys will be copied to loader/keys subdirectory of the ESP. after installing systemd-boot to the system. More information on how key enrollment works with systemd-boot is available in the systemd-boot ⟨https://github.com/systemd/systemd/blob/26b2085d54ebbfca8637362eafcb4a8e3faf832f/man/systemd-boot.xml#L392⟩ man page. <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## SUBCOMMANDS<!-- BEGIN GENERATED SUBCOMMANDS -->
Command

Description

bootc install to-disk

Install to the target block device

bootc install to-filesystem

Install to an externally created filesystem structure

bootc install to-existing-root

Install to the host root filesystem

bootc install finalize

Execute this as the penultimate step of an installation using install to-filesystem

bootc install ensure-completion

Intended for use in environments that are performing an ostree-based installation, not bootc

bootc install print-configuration

Output JSON to stdout that contains the merged installation configuration as it may be relevant to calling processes using install to-filesystem that in particular want to discover the desired root filesystem type from the container image

<!-- END GENERATED SUBCOMMANDS -->

## VERSION
v1.16.4


bootc-install-ensure-completion

title: bootc-install-ensure-completion(8)

summary: completion [OPTIONS...]

text:
# bootc-install-ensure-completion(8)

bootc-install-ensure-completion - Intended for use in environments that are performing an ostree-based installation, not bootc

## SYNOPSIS
bootc install ensure-completion [OPTIONS...]

## DESCRIPTION
Intended for use in environments that are performing an ostree-based installation, not bootc.

In this scenario the installation may be missing bootc specific features such as kernel arguments, logically bound images and more. This command can be used to attempt to reconcile. At the current time, the only tested environment is Anaconda using ostreecontainer and it is recommended to avoid usage outside of that environment. Instead, ensure your code is using bootc install to-filesystem from the start. <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-install-finalize

title: bootc-install-finalize(8)

text:
# bootc-install-finalize(8)

bootc-install-finalize - Execute this as the penultimate step of an installation using install to-filesystem

## SYNOPSIS
bootc install finalize [OPTIONS...] <ROOT_PATH>

## DESCRIPTION
Execute this as the penultimate step of an installation using install to-filesystem

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
ROOT_PATH

```
Path to the mounted root filesystem
This argument is required.
```

<!-- END GENERATED OPTIONS -->

## ARGUMENTS
<ROOT_PATH>

: Path to the mounted root filesystem

## VERSION
v1.16.4


bootc-install-print-configuration

title: bootc-install-print-configuration(8)

summary: configuration [OPTIONS...]

text:
# bootc-install-print-configuration(8)

bootc-install-print-configuration - Output JSON to stdout that contains the merged installation configuration as it may be relevant to calling processes using install to-filesystem that in particular want to discover the desired root filesystem type from the container image

## SYNOPSIS
bootc install print-configuration [OPTIONS...]

## DESCRIPTION
Output JSON to stdout that contains the merged installation configuration as it may be relevant to calling processes using install to-filesystem that in particular want to discover the desired root filesystem type from the container image.

At the current time, the only output key is root-fs-type which is a string-valued filesystem name suitable for passing to mkfs.\$type.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--all

```
Print all configuration
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-install-to-disk

title: bootc-install-to-disk(8)

summary: disk [OPTIONS...] <DEVICE>

text:
# bootc-install-to-disk(8)

bootc-install-to-disk - Install to the target block device

## SYNOPSIS
bootc install to-disk [OPTIONS...] <DEVICE>

## DESCRIPTION
Install to the target block device.

This command must be invoked inside of the container, which will be installed. The container must be run in --privileged mode, and hence will be able to see all block devices on the system.

The default storage layout uses the root filesystem type configured in the container image, alongside any required system partitions such as the EFI system partition. Use install to-filesystem for anything more complex such as RAID, LVM, LUKS etc.

## Partitioning details
The default as of bootc 1.11 uses the Discoverable Partitions Specification ⟨https://uapi-group.org/specifications/specs/discoverable_partitions_specification/⟩ (DPS) for the generated root filesystem, as well as any required system partitions such as the EFI system partition.

### Partition layout
The installer creates a GPT partition table with architecture-appropriate partitions. The exact layout varies by architecture but generally includes:

- Boot partition (architecture-specific): BIOS boot for x86_64, PReP for ppc64le, etc.

- ESP: EFI System Partition on UEFI architectures (x86_64, aarch64), at least 512 MiB

- Boot: Separate /boot partition, only created when using LUKS encryption

- Root: The root filesystem, using the remaining disk space

The root partition uses an architecture-specific DPS type GUID. Specific partition sizes and type GUIDs are implementation details that may change between versions; use install to-filesystem if you need precise control over the partition layout.

### Root filesystem discovery
The root partition can be discovered at boot time in two ways:

•

UUID mode (default): A kernel argument root=UUID=<uuid> is injected, providing broad compatibility with all initramfs implementations and bootloaders.

•

DPS auto-discovery: The root= kernel argument is omitted entirely. systemd-gpt-auto-generator in the initramfs discovers the root partition by its DPS type GUID. This enables transparent block-layer changes (such as adding LUKS encryption) without updating kernel arguments. DPS auto-discovery requires the bootloader to implement the Boot Loader Interface (BLI). systemd-boot always supports this; GRUB supports it only with newer builds that include the bli module.

When using systemd-boot, DPS auto-discovery is enabled by default. For GRUB, container base images that ship a BLI-capable build should set discoverable-partitions = true in their install configuration (see bootc-install-config(5)).

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
DEVICE

```
Target block device for installation.  The entire device will be wiped
This argument is required.
```

--wipe

```
Automatically wipe all existing data on device
```

--block-setup=BLOCK_SETUP

```
Target root block device setup
Possible values:
- direct
- tpm2-luks
```

--filesystem=FILESYSTEM

```
Target root filesystem type
Possible values:
- xfs
- ext4
- btrfs
```

--root-size=ROOT_SIZE

```
Size of the root partition (default specifier: M).  Allowed specifiers: M (mebibytes), G (gibibytes), T (tebibytes)
```

--source-imgref=SOURCE_IMGREF

```
Install the system from an explicitly given source
```

--target-transport=TARGET_TRANSPORT

```
The transport; e.g. oci, oci-archive, containers-storage.  Defaults to `registry`
Default: registry
```

--target-imgref=TARGET_IMGREF

```
Specify the image to fetch for subsequent updates
```

--enforce-container-sigpolicy

```
This is the inverse of the previous `--target-no-signature-verification` (which is now a no-op).  Enabling this option enforces that `containers-policy.json` (see `man containers-policy.json` for the full search path) includes a default policy which requires signatures
```

--run-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--skip-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--disable-selinux

```
Disable SELinux in the target (installed) system
```

--karg=KARG

```
Add a kernel argument.  This option can be provided multiple times
```

--karg-delete=KARG_DELETE

```
Remove a kernel argument.  This option can be provided multiple times
```

--root-ssh-authorized-keys=ROOT_SSH_AUTHORIZED_KEYS

```
The path to an `authorized_keys` that will be injected into the `root` account
```

--generic-image

```
Perform configuration changes suitable for a "generic" disk image. At the moment:
```

--bound-images=BOUND_IMAGES

```
How should logically bound images be retrieved
Possible values:
- stored
- skip
- pull
Default: stored
```

--stateroot=STATEROOT

```
The stateroot name to use. Defaults to `default`
```

--bootupd-skip-boot-uuid

```
Don't pass --write-uuid to bootupd during bootloader installation
```

--bootloader=BOOTLOADER

```
The bootloader to use
Possible values:
- grub
- grub-cc
- systemd
- none
```

--via-loopback

```
Instead of targeting a block device, write to a file via loopback
```

--composefs-backend

```
If true, composefs backend is used, else ostree backend is used
Default: false
```

--allow-missing-verity

```
Make fs-verity validation optional in case the filesystem doesn't support it
Default: false
```

--uki-addon=UKI_ADDON

```
Name of the UKI addons to install without the ".efi.addon" suffix. This option can be provided multiple times if multiple addons are to be installed
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Install to a disk, wiping all existing data:

```
bootc install to-disk --wipe /dev/sda
```

Install with a specific root filesystem type:

```
bootc install to-disk --filesystem xfs /dev/nvme0n1
```

Install with TPM2 LUKS encryption:

```
bootc install to-disk --block-setup tpm2-luks /dev/sda
```

Install with custom kernel arguments:

```
bootc install to-disk --karg=nosmt --karg=console=ttyS0 /dev/sda
```

## SEE ALSO
bootc(8), bootc-install(8), bootc-install-to-filesystem(8)

## VERSION
v1.16.4


bootc-install-to-existing-root

title: bootc-install-to-existing-root(8)

summary: existing\-root [OPTIONS...] [ROOT\_PATH]

text:
# bootc-install-to-existing-root(8)

bootc-install-to-existing-root - Install to the host root filesystem

## SYNOPSIS
bootc install to-existing-root [OPTIONS...] [ROOT_PATH]

## DESCRIPTION
Install to the host root filesystem.

This is a variant of install to-filesystem that is designed to install \"alongside\" the running host root filesystem. Currently, the host root filesystem\'s /boot partition will be wiped, but the content of the existing root will otherwise be retained, and will need to be cleaned up if desired when rebooted into the new root.

## Managing configuration: before and after reboot
When using to-existing-root, there are two distinct scenarios for managing configuration files:

1.

Before rebooting: Injecting new configuration into the newly installed system

2.

After rebooting: Migrating configuration from the old system to the new system

### Before reboot: Injecting new configuration
If you need to inject new configuration files (such as custom /etc/fstab entries, systemd mount units, or other configuration) into the newly installed system before rebooting, you can find the deployment directory in the ostree repository structure. The new deployment is located at:

```
/ostree/deploy/<stateroot>/deploy/<checksum>.<serial>/
```

Where <stateroot> defaults to default unless you specified a different value with --stateroot.

To find the path to the newly installed deployment:

```
# Get the full deployment path directly
DEPLOY_PATH=$(ostree admin --sysroot=/target --print-current-dir)
```

This will return the full path, for example: /target/ostree/deploy/default/deploy/807f233831a03d315289a4ba29c1670d8bd326d4569eabee7a84f25327997307.0

You can then modify files in that deployment. For example, to add systemd mount units:

```
# Get deployment path
DEPLOY_PATH=$(ostree admin --sysroot=/target --print-current-dir)
# Add a systemd mount unit
vi ${DEPLOY_PATH}/etc/systemd/system/data.mount
```

### Injecting kernel arguments for local state
A better approach for machine-local configuration like filesystem mounts is to inject kernel arguments during installation. Kernel arguments are ideal for local/machine-specific state in a bootc system.

For filesystem mounts, use systemd.mount-extra instead of /etc/fstab:

```
# Add a mount via kernel argument (preferred over /etc/fstab)
bootc install to-existing-root \

  --karg="systemd.mount-extra=UUID=<uuid>:/data:xfs:defaults"
```

The systemd.mount-extra syntax is: source:path:type:options

You can also inject other local kernel arguments for machine-specific configuration:

```
# Add console settings for serial access
bootc install to-existing-root --karg="console=ttyS0,115200"
# Add storage-specific options
bootc install to-existing-root --karg="rootflags=subvol=root"
```

This approach is cleaner than editing configuration files because kernel arguments are explicitly designed for local/machine-specific state in a bootc system.

Note: In the future, this functionality will be provided via a dedicated bootc API to make finding and modifying the deployment more straightforward.

### After reboot: Migrating data from the old system
After rebooting into the new bootc system, the previous root filesystem data is accessible at /sysroot (the "physical root"). This allows you to migrate data from the old system to the new one.

Important: Any configuration data from /etc that you want to use in the new system must be manually copied from /sysroot/etc to /etc after rebooting. There is currently no automated mechanism for migrating this data.

For example, to migrate configuration after rebooting:

```
# After rebooting into the new system
# Copy network configuration from the old system
cp /sysroot/etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/
# Copy application configuration
cp -r /sysroot/etc/myapp /etc/
# Selectively merge configuration files
vi /etc/resolv.conf  # Add nameservers from /sysroot/etc/resolv.conf
# For user accounts, use proper tools
vipw  # Carefully review and merge users from /sysroot/etc/passwd
```

This applies to network configurations, user accounts, application settings, and other system configuration stored in /etc. Review files in /sysroot/etc and manually copy or merge what you need into /etc.

Note: For filesystem mounts from /etc/fstab in the old system, consider using kernel arguments (via systemd.mount-extra) injected before reboot instead of migrating the fstab entries. See the "Injecting kernel arguments" section above.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
ROOT_PATH

```
Path to the mounted root; this is now not necessary to provide. Historically it was necessary to ensure the host rootfs was mounted at here via e.g. `-v /:/target`
```

--replace=REPLACE

```
Configure how existing data is treated
Possible values:
- wipe
- alongside
Default: alongside
```

--source-imgref=SOURCE_IMGREF

```
Install the system from an explicitly given source
```

--target-transport=TARGET_TRANSPORT

```
The transport; e.g. oci, oci-archive, containers-storage.  Defaults to `registry`
Default: registry
```

--target-imgref=TARGET_IMGREF

```
Specify the image to fetch for subsequent updates
```

--enforce-container-sigpolicy

```
This is the inverse of the previous `--target-no-signature-verification` (which is now a no-op).  Enabling this option enforces that `containers-policy.json` (see `man containers-policy.json` for the full search path) includes a default policy which requires signatures
```

--run-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--skip-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--disable-selinux

```
Disable SELinux in the target (installed) system
```

--karg=KARG

```
Add a kernel argument.  This option can be provided multiple times
```

--karg-delete=KARG_DELETE

```
Remove a kernel argument.  This option can be provided multiple times
```

--root-ssh-authorized-keys=ROOT_SSH_AUTHORIZED_KEYS

```
The path to an `authorized_keys` that will be injected into the `root` account
```

--generic-image

```
Perform configuration changes suitable for a "generic" disk image. At the moment:
```

--bound-images=BOUND_IMAGES

```
How should logically bound images be retrieved
Possible values:
- stored
- skip
- pull
Default: stored
```

--stateroot=STATEROOT

```
The stateroot name to use. Defaults to `default`
```

--bootupd-skip-boot-uuid

```
Don't pass --write-uuid to bootupd during bootloader installation
```

--bootloader=BOOTLOADER

```
The bootloader to use
Possible values:
- grub
- grub-cc
- systemd
- none
```

--acknowledge-destructive

```
Accept that this is a destructive action and skip a warning timer
```

--cleanup

```
Add the bootc-destructive-cleanup systemd service to delete files from the previous install on first boot
```

--composefs-backend

```
If true, composefs backend is used, else ostree backend is used
Default: false
```

--allow-missing-verity

```
Make fs-verity validation optional in case the filesystem doesn't support it
Default: false
```

--uki-addon=UKI_ADDON

```
Name of the UKI addons to install without the ".efi.addon" suffix. This option can be provided multiple times if multiple addons are to be installed
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-install-to-filesystem

title: bootc-install-to-filesystem(8)

summary: filesystem [OPTIONS...] <ROOT\_PATH>

text:
# bootc-install-to-filesystem(8)

bootc-install-to-filesystem - Install to an externally created filesystem structure

## SYNOPSIS
bootc install to-filesystem [OPTIONS...] <ROOT_PATH>

## DESCRIPTION
Install to an externally created filesystem structure.

In this variant of installation, the root filesystem alongside any necessary platform partitions (such as the EFI system partition) are prepared and mounted by an external tool or script. The root filesystem is currently expected to be empty by default.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
ROOT_PATH

```
Path to the mounted root filesystem
This argument is required.
```

--root-mount-spec=ROOT_MOUNT_SPEC

```
Source device specification for the root filesystem.  For example, `UUID=2e9f4241-229b-4202-8429-62d2302382e1`. If not provided, the UUID of the target filesystem will be used. This option is provided as some use cases might prefer to mount by a label instead via e.g. `LABEL=rootfs`
```

--boot-mount-spec=BOOT_MOUNT_SPEC

```
Mount specification for the /boot filesystem
```

--replace=REPLACE

```
Initialize the system in-place; at the moment, only one mode for this is implemented. In the future, it may also be supported to set up an explicit "dual boot" system
Possible values:
- wipe
- alongside
```

--acknowledge-destructive

```
If the target is the running system's root filesystem, this will skip any warnings
```

--skip-finalize

```
The default mode is to "finalize" the target filesystem by invoking `fstrim` and similar operations, and finally mounting it readonly.  This option skips those operations.  It is then the responsibility of the invoking code to perform those operations
```

--source-imgref=SOURCE_IMGREF

```
Install the system from an explicitly given source
```

--target-transport=TARGET_TRANSPORT

```
The transport; e.g. oci, oci-archive, containers-storage.  Defaults to `registry`
Default: registry
```

--target-imgref=TARGET_IMGREF

```
Specify the image to fetch for subsequent updates
```

--enforce-container-sigpolicy

```
This is the inverse of the previous `--target-no-signature-verification` (which is now a no-op).  Enabling this option enforces that `containers-policy.json` (see `man containers-policy.json` for the full search path) includes a default policy which requires signatures
```

--run-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--skip-fetch-check

```
Verify the image can be fetched from the bootc image. Updates may fail when the installation host is authenticated with the registry but the pull secret is not in the bootc image
```

--disable-selinux

```
Disable SELinux in the target (installed) system
```

--karg=KARG

```
Add a kernel argument.  This option can be provided multiple times
```

--karg-delete=KARG_DELETE

```
Remove a kernel argument.  This option can be provided multiple times
```

--root-ssh-authorized-keys=ROOT_SSH_AUTHORIZED_KEYS

```
The path to an `authorized_keys` that will be injected into the `root` account
```

--generic-image

```
Perform configuration changes suitable for a "generic" disk image. At the moment:
```

--bound-images=BOUND_IMAGES

```
How should logically bound images be retrieved
Possible values:
- stored
- skip
- pull
Default: stored
```

--stateroot=STATEROOT

```
The stateroot name to use. Defaults to `default`
```

--bootupd-skip-boot-uuid

```
Don't pass --write-uuid to bootupd during bootloader installation
```

--bootloader=BOOTLOADER

```
The bootloader to use
Possible values:
- grub
- grub-cc
- systemd
- none
```

--composefs-backend

```
If true, composefs backend is used, else ostree backend is used
Default: false
```

--allow-missing-verity

```
Make fs-verity validation optional in case the filesystem doesn't support it
Default: false
```

--uki-addon=UKI_ADDON

```
Name of the UKI addons to install without the ".efi.addon" suffix. This option can be provided multiple times if multiple addons are to be installed
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


bootc-loader-entries

title: bootc-loader-entries(8)

summary: entries COMMAND

text:
# bootc-loader-entries(8)

bootc-loader-entries - Operations on Boot Loader Specification (BLS) entries

## SYNOPSIS
bootc loader-entries COMMAND

## DESCRIPTION
Manage kernel arguments from multiple independent sources by tracking argument ownership via x-options-source-<name> extension keys in BLS config files.

This solves the problem of kernel argument accumulation on bootc systems with transient /etc, where tools like TuneD lose their state files on reboot and cannot track which kargs they previously set. <!-- BEGIN GENERATED OPTIONS --><!-- END GENERATED OPTIONS -->

## COMMANDS
set-options-for-source : Set or update the kernel arguments owned by a specific source.

## SEE ALSO
bootc(8), bootc-loader-entries-set-options-for-source(8)

## VERSION
v1.16.4


summary: entries set\-options\-for\-source \-\-source NAME [\-\-options KARGS]

text:
# bootc-loader-entries-set-options-for-source(8)

bootc-loader-entries-set-options-for-source - Set or update the kernel arguments owned by a specific source

## SYNOPSIS
bootc loader-entries set-options-for-source --source NAME [--options "KARGS"]

## DESCRIPTION
Set or update the kernel arguments owned by a specific source. Each source's arguments are tracked via x-options-source-<name> extension keys in BLS config files on /boot. The options line is recomputed as the merge of all tracked sources plus any untracked (pre-existing) options.

This command stages a new deployment with the updated kernel arguments. Changes take effect on the next reboot.

When a staged deployment already exists (e.g. from bootc upgrade), it is replaced using the staged deployment's commit and origin, preserving the pending upgrade while layering the kargs change on top.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--source=SOURCE

```
The name of the source that owns these kernel arguments
```

--options=OPTIONS

```
The kernel arguments to set for this source
```

<!-- END GENERATED OPTIONS -->

## REQUIREMENTS
This command requires ostree >= 2026.1 with bootconfig-extra support for preserving extension BLS keys through staged deployment roundtrips. On older ostree versions, the command will exit with an error.

## EXAMPLES
Add TuneD kernel arguments:

```
bootc loader-entries set-options-for-source --source tuned \

    --options "isolcpus=1-3 nohz_full=1-3"
```

Update TuneD kernel arguments (replaces previous values):

```
bootc loader-entries set-options-for-source --source tuned \

    --options "isolcpus=0-7"
```

Remove all kernel arguments owned by TuneD:

```
bootc loader-entries set-options-for-source --source tuned
```

Multiple sources can coexist independently:

```
bootc loader-entries set-options-for-source --source tuned \

    --options "nohz=full isolcpus=1-3"
bootc loader-entries set-options-for-source --source dracut \

    --options "rd.driver.pre=vfio-pci"
```

## KNOWN LIMITATIONS
Source keys set by prior calls in the same boot cycle (before any reboot) are discovered by reading the staged deployment data file at /run/ostree/staged-deployment. If this file is missing or cannot be parsed, sources from prior calls may not be discovered, potentially orphaning their kargs. In practice this should not occur, as the file is managed by ostree and always present when a staged deployment exists.

## SEE ALSO
bootc(8), bootc-loader-entries(8)

## VERSION
v1.16.4


bootc-rollback

title: bootc-rollback(8)

text:
# bootc-rollback(8)

bootc-rollback - Change the bootloader entry ordering

## SYNOPSIS
bootc rollback [OPTIONS...]

## DESCRIPTION
Change the bootloader entry ordering; the deployment under rollback will be queued for the next boot, and the current will become rollback. If there is a staged entry (an unapplied, queued upgrade) then it will be discarded.

Note that absent any additional control logic, if there is an active agent doing automated upgrades (such as the default bootc-fetch-apply-updates.timer and associated .service) the change here may be reverted. It's recommended to only use this in concert with an agent that is in active control.

A systemd journal message will be logged with MESSAGE_ID=26f3b1eb24464d12aa5e7b544a6b5468 in order to detect a rollback invocation.

## Note on Rollbacks and the /etc Directory
When you perform a rollback (e.g., with bootc rollback), any changes made to files in the /etc directory won't carry over to the rolled-back deployment. The /etc files will revert to their state from that previous deployment instead.

This is because bootc rollback just reorders the existing deployments. It doesn't create new deployments. The /etc merges happen when new deployments are created.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--apply

```
Restart or reboot into the rollback image
```

--soft-reboot=SOFT_REBOOT

```
Configure soft reboot behavior
Possible values:
- required
- auto
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Rollback to the previous deployment:

```
bootc rollback
```

Rollback and immediately apply the changes:

```
bootc rollback --apply
```

Rollback with soft reboot if possible:

```
bootc rollback --apply --soft-reboot=auto
```

## SEE ALSO
bootc(8), bootc-upgrade(8), bootc-switch(8), bootc-status(8)

## VERSION
v1.16.4


bootc-status

title: bootc-status(8)

text:
# bootc-status(8)

bootc-status - Display status

## SYNOPSIS
bootc status [OPTIONS...]

## DESCRIPTION
Display status.

If standard output is a terminal, this will output a description of the bootc system state. If standard output is not a terminal, output a YAML-formatted object using a schema intended to match a Kubernetes resource that describes the state of the booted system.

## Parsing output via programs
Either the default YAML format or --format=json can be used. Do not attempt to explicitly parse the output of --format=humanreadable as it will very likely change over time.

## Programmatically detecting whether the system is deployed via bootc
Invoke e.g. bootc status --json, and check if status.booted is not null.

### Detecting rpm-ostree vs bootc
There is no "bootc runtime". When used with the default ostree backend, bootc and tools like rpm-ostree end up sharing the same code and doing effectively the same thing. Hence, there isn't a mechanism to detect if a system "is bootc" or "is rpm-ostree".

However, if the incompatible flag is set on a deployment, then there are layered packages and rpm-ostree must be used for mutation.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--format=FORMAT

```
The output format
Possible values:
- humanreadable
- yaml
- json
```

--format-version=FORMAT_VERSION

```
The desired format version. There is currently one supported version, which is exposed as both `0` and `1`. Pass this option to explicitly request it; it is possible that another future version 2 or newer will be supported in the future
```

--booted

```
Only display status for the booted deployment
```

-v, --verbose

```
Include additional fields in human readable format
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Show current system status:

```
bootc status
```

Show status in JSON format:

```
bootc status --format=json
```

Show detailed status with verbose output:

```
bootc status --verbose
```

Show only booted deployment status:

```
bootc status --booted
```

## SEE ALSO
bootc(8), bootc-upgrade(8), bootc-switch(8), bootc-rollback(8)

## VERSION
v1.16.4


bootc-switch

title: bootc-switch(8)

text:
# bootc-switch(8)

bootc-switch - Target a new container image reference to boot

## SYNOPSIS
bootc switch [OPTIONS...] <TARGET>

## DESCRIPTION
Target a new container image reference to boot.

This is almost exactly the same operation as upgrade, but additionally changes the container image reference instead.

## Usage
A common pattern is to have a management agent control operating system updates via container image tags; for example, quay.io/exampleos/someuser:v1.0 and quay.io/exampleos/someuser:v1.1 where some machines are tracking :v1.0, and as a rollout progresses, machines can be switched to v:1.1.

It is also supported to provide explicit digests, via e.g. bootc switch quay.io/exampleos/someuser@sha256:9cca0703342e24806a9f64e08c053dca7f2cd90f10529af8ea872afb0a0c77d4. When you do this, bootc upgrade will always be a no-op. In this model, upgrades are then always triggered by further switch operations.

## Applying Changes
The --apply option will automatically take action (rebooting) if the system has changed after switching to the new image. Currently, this option always reboots the system. In the future, this command may detect cases where no kernel changes are queued and perform a userspace-only restart instead.

## Soft Reboot
The --soft-reboot option configures soft reboot behavior when used with --apply:

- required: The operation will fail if soft reboot is not available on the target system

- auto: Uses soft reboot if available on the target system, otherwise falls back to a regular reboot

Soft reboot allows faster system restart by avoiding full hardware reboot when possible.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
TARGET

```
Target image to use for the next boot
This argument is required.
```

--quiet

```
Don't display progress
```

--apply

```
Restart or reboot into the new target image
```

--soft-reboot=SOFT_REBOOT

```
Configure soft reboot behavior
Possible values:
- required
- auto
```

--transport=TRANSPORT

```
The transport; e.g. registry, oci, oci-archive, docker-daemon, containers-storage.  Defaults to `registry`
Default: registry
```

--enforce-container-sigpolicy

```
This is the inverse of the previous `--target-no-signature-verification` (which is now a no-op)
```

--retain

```
Retain reference to currently booted image
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Switch to a different image version:

```
bootc switch quay.io/exampleos/myapp:v1.1
```

Switch and immediately apply the changes:

```
bootc switch --apply quay.io/exampleos/myapp:v1.1
```

Switch with soft reboot if possible:

```
bootc switch --apply --soft-reboot=auto quay.io/exampleos/myapp:v1.1
```

## SEE ALSO
bootc(8), bootc-upgrade(8), bootc-status(8), bootc-rollback(8)

## VERSION
v1.16.4


bootc-upgrade

title: bootc-upgrade(8)

text:
# bootc-upgrade(8)

bootc-upgrade - Download and queue an updated container image to apply

## SYNOPSIS
bootc upgrade [OPTIONS...]

## DESCRIPTION
Download and queue an updated container image to apply.

This does not affect the running system; updates operate in an "A/B" style by default.

A queued update is visible as staged in bootc status.

## Checking for Updates
The --check option allows you to verify if updates are available without downloading the full image layers. This only downloads the updated manifest and image configuration (typically kilobyte-sized metadata), making it much faster than a full upgrade.

## Applying Updates
Currently by default, the update will be applied at shutdown time via ostree-finalize-staged.service. There is also an explicit bootc upgrade --apply verb which will automatically take action (rebooting) if the system has changed.

The --apply option currently always reboots the system. In the future, this command may detect cases where no kernel changes are queued and perform a userspace-only restart instead.

However, in the future this is likely to change such that reboots outside of a bootc upgrade --apply do not automatically apply the update in addition.

## Soft Reboot
The --soft-reboot option configures soft reboot behavior when used with --apply:

- required: The operation will fail if soft reboot is not available on the target system

- auto: Uses soft reboot if available on the target system, otherwise falls back to a regular reboot

Soft reboot allows faster system restart by avoiding full hardware reboot when possible.

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--quiet

```
Don't display progress
```

--check

```
Check if an update is available without applying it
```

--apply

```
Restart or reboot into the new target image
```

--soft-reboot=SOFT_REBOOT

```
Configure soft reboot behavior
Possible values:
- required
- auto
```

--download-only

```
Download and stage the update without applying it
```

--from-downloaded

```
Apply a staged deployment that was previously downloaded with --download-only
```

--tag=TAG

```
Upgrade to a different tag of the currently booted image
```

<!-- END GENERATED OPTIONS -->

## EXAMPLES
Check for available updates:

```
bootc upgrade --check
```

Upgrade and immediately apply the changes:

```
bootc upgrade --apply
```

Upgrade with soft reboot if possible:

```
bootc upgrade --apply --soft-reboot=auto
```

Upgrade to a different tag:

```
bootc upgrade --tag v1.2
```

Check if a specific tag has updates before applying:

```
bootc upgrade --tag prod --check
```

Upgrade to a tag and immediately apply:

```
bootc upgrade --tag v2.0 --apply
```

## SEE ALSO
bootc(8), bootc-switch(8), bootc-status(8), bootc-rollback(8)

## VERSION
v1.16.4


bootc-usr-overlay

title: bootc-usr-overlay(8)

summary: overlay [OPTIONS...]

text:
# bootc-usr-overlay(8)

bootc-usr-overlay - Adds a transient overlayfs on /usr that will be discarded on reboot

## SYNOPSIS
bootc usr-overlay [OPTIONS...]

## DESCRIPTION
Adds a transient overlayfs on /usr that will be discarded on reboot. The overlayfs is read/write by default.

## USE CASES
A common pattern is wanting to use tracing/debugging tools, such as strace that may not be in the base image. A system package manager such as apt or dnf can apply changes into this transient overlay that will be discarded on reboot.

## /ETC AND /VAR
However, this command has no effect on /etc and /var - changes written there will persist. It is common for package installations to modify these directories.

## UNMOUNTING
Almost always, a system process will hold a reference to the open mount point. You can however invoke umount -l /usr to perform a "lazy unmount".

## OPTIONS<!-- BEGIN GENERATED OPTIONS -->
--read-only

```
Mount the overlayfs as read-only. A read-only overlayfs is useful since it may be remounted as read/write in a private mount namespace and written to while the mount point remains read-only to the rest of the system
```

<!-- END GENERATED OPTIONS -->

## VERSION
v1.16.4


system-reinstall-bootc

title: system-reinstall-bootc(8)

summary: reinstall\-bootc <BOOTC\_IMAGE>

text:
# system-reinstall-bootc(8)

system-reinstall-bootc - Reinstall the current system with a bootc image

## SYNOPSIS
system-reinstall-bootc <BOOTC_IMAGE>

## DESCRIPTION
system-reinstall-bootc is a utility that allows you to reinstall your current system using a bootc container image. This tool provides an interactive way to replace your existing system with a new bootc-based system while preserving SSH access and making the previous root filesystem (including user data) available in /sysroot.

The utility will: - Pull the specified bootc container image - Collect SSH keys for root access after reinstall - Execute a bootc install to replace the current system - Reboot into the new system

After reboot, the previous root filesystem will be available in /sysroot, and some automatic cleanup of the previous root will be performed. Note that existing mounts will not be automatically mounted by the bootc system unless they are defined in the bootc image.

This is primarily intended as a way to "take over" cloud virtual machine images, effectively using them as an installer environment.

## ARGUMENTS
BOOTC_IMAGE

```
The bootc container image to install (e.g., quay.io/fedora/fedora-bootc:41)
This argument is required.
```

## EXAMPLES
Reinstall with a custom bootc image:

```
system-reinstall-bootc registry.example.com/my-bootc:latest
```

## ENVIRONMENT
BOOTC_REINSTALL_CONFIG

```
This variable is deprecated.
```

## SEE ALSO
bootc(8), bootc-install(8)

## VERSION
v1.16.4


rebootin

package: bootloader-utils

title: rebootin(8)

text:
# rebootin(8)

## NAME
rebootin - Reboots the machine using a particular Boot Loader entry

## SYNOPSIS
rebootin [OPTIONS] <label>

## DESCRIPTION
rebootin reboots the machine it is launched on. While with a simple reboot you need to manually select the boot entry to use at startup, rebootin allows to specify the boot entry on the command line.

<label> is the name of the entry as named in the boot loader configuration file.

rebootin currently works only with LILO.

## OPTIONS
-f, --fastboot

Create a /fastboot file to reboot in fastboot mode (eg: no fsck(8)).

-n, --noreboot

Don't reboot immediately just set the flags for next reboot.

-l, --list

Display the list of available boot entries.

-h, --help

Show help.

## FILES
/etc/lilo.conf /boot/grub/menu.lst

The rebootin executable (perl script)

## SEE ALSO
grub(8), lilo(8), fsck(8)

## AUTHORS
Pascal Rigaux, Mandrakesoft

pixel@mandrakesoft.com

Chmouel Boudjnah, Mandrakesoft

chmouel@mandrakesoft.com


bpfmon

package: bpfmon

title: bpfmon(8)

summary: BPF based visual packet rate monitor

text:
# bpfmon(8)

## NAME
bpfmon - BPF based visual packet rate monitor

## SYNOPSIS
bpfmon

bpfmon [-autzvIiLlnNh] <device> '<bpf_filter_code>'

bpfmon [-autzvIiLlnNh] iptables '[<table>] <chain> <rulenum>'

bpfmon [-autzvIiLlnNh] iptables [select]

bpfmon [-autzvIiLlnNh] ip6tables '[<table>] <chain> <rulenum>'

bpfmon [-autzvIiLlnNh] ip6tables [select]

## DESCRIPTION
bpfmon (like tcpdump) uses BPF filter to select packets that match the filter. While with tcpdump it is easy to see what packets match the filter, bpfmon shows how much are the matches packets in terms of bytes per second and packets per second.

bpfmon displays the information in pseudo-graphical text interface, developed for modern terminals, but it also supports pure ASCII display.

In addition, bpfmon allows instead of monitoring packets matching a BPF filter to get its data from an iptables/ip6tables rule (on Linux systems).

In interactive mode, there are hot keys to display help or modify the mode of operation.

Without any arguments, bpfmon will display its version and options help.

## OPTIONS
-a

Use ASCII drawing characters

-u

Use UTF-8 drawing characters

-t

Use no interface (simple text output)

-z

Use horizontal full-screen interface

-v

Use vertical full-screen interface

-I

Show history in vertical full-screen

-i

Hide history in vertical full-screen

-L

Show legend in vertical full-screen

-l

Hide legend in vertical full-screen -n Show interface white on black

-N

Show interface inverse (black on white)

-h

Show usage information and exit

## KEYBOARD SHORTCUTS
h, H, ?

Toggle help screen

a, A

switch to ASCII drawing chars

u, U

switch to UTF-8 drawing chars

m, M

toggle horizontal/vertical mode

i, I

toggle history in vertical mode

l, L

toggle legend in vertical mode

n, N

toggle inverse mode

z, Z

zero history and restart

s, S

iptables rule select

6

ip6tables rule select

r, R, Ctrl-L

refresh screen

q, Q, Ctrl-C

Exit

## SEE ALSO
tcpdump(8), bpf(4), pcap-filter(7) iptables(8),

## AUTHOR
The bpfmon program was written by Boian Bonev from 2014 to 2024.

This manual page was written by Boian Bonev for the Debian project and is placed in the public domain.


bpftool

package: bpftool

title: bpftool(8)

text:
# bpftool(8)

## Name
BPFTOOL - tool for inspection and simple manipulation of eBPF programs and maps

## SYNOPSIS
bpftool [OPTIONS] OBJECT { COMMAND | help }

bpftool batch file FILE

bpftool version

OBJECT := { map | prog | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }

OPTIONS := { { -V | --version } | { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

MAP-COMMANDS := { show | list | create | dump | update | lookup | getnext | delete | pin | event_pipe | help }

PROG-COMMANDS := { show | list | dump jited | dump xlated | pin | load | attach | detach | help }

LINK-COMMANDS := { show | list | pin | detach | help }

CGROUP-COMMANDS := { show | list | attach | detach | help }

PERF-COMMANDS := { show | list | help }

NET-COMMANDS := { show | list | help }

FEATURE-COMMANDS := { probe | help }

BTF-COMMANDS := { show | list | dump | help }

GEN-COMMANDS := { object | skeleton | min_core_btf | help }

STRUCT-OPS-COMMANDS := { show | list | dump | register | unregister | help }

ITER-COMMANDS := { pin | help }

## DESCRIPTION
bpftool allows for inspection and simple modification of BPF objects on the system.

Note that format of the output of all tools is not guaranteed to be stable and should not be depended upon.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-m, --mapcompat

Allow loading maps with unknown map definitions.

-n, --nomount

Do not automatically attempt to mount any virtual file system (such as tracefs or BPF virtual file system) when necessary.

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)