### Setup commands for sysvinit in a VM

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

These setup commands are used to configure a VM to run autopkgtest with sysvinit, ensuring it has a console on ttyS0. This involves installing sysvinit-core and modifying /etc/inittab.

```bash
--setup-commands 'apt-get install -y --allow-remove-essential sysvinit-core
    systemd-sysv- ; sed -i "/ttyS0/ s/^#//" /etc/inittab'
```

--------------------------------

### Prepare for Self-Initiated Reboot in Test

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

This example shows how to prepare for a reboot that is initiated by the software under test. It uses '/tmp/autopkgtest-reboot-prepare' to save the test state before the actual reboot occurs. Logs and artifacts created after this call but before the reboot will be lost.

```shell
#!/bin/sh
if [ "$AUTOPKGTEST_REBOOT_MARK" = phase1 ]; then

```

--------------------------------

### Get Virtualisation Server Capabilities

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Queries the virtualisation server for its supported capabilities. This command is valid in all server states.

```bash
capabilities
```

--------------------------------

### Simplest control file for a standalone test

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

Installs all binary packages and runs the standalone debian/tests/smoke test script as a regular user.

```rst
Tests: smoke
```

--------------------------------

### Example of Rebooting Test Logic

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

This script demonstrates how to handle reboots within a test. It uses the AUTOPKGTEST_REBOOT_MARK environment variable to resume execution at different stages after a reboot. The test will reboot twice.

```shell
#!/bin/sh -e
case "$AUTOPKGTEST_REBOOT_MARK" in
  "") echo "test beginning"; /tmp/autopkgtest-reboot mark1 ;; 
  mark1) echo "test in mark1"; /tmp/autopkgtest-reboot mark2 ;; 
  mark2) echo "test in mark2" ;; 
esac
echo "test end"
```

--------------------------------

### Run tests via SSH on a remote host

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

This command runs tests on a remote machine accessible via SSH. It's a generic runner that can utilize setup scripts for configuring testbeds like cloud VMs or mobile devices.

```bash
autopkgtest ... -- ssh -l joe -H testhost.example.com
```

--------------------------------

### Open Virtualisation Testbed

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Opens the virtualisation testbed, making it available for use. It returns the path to a scratchspace directory on the testbed that is valid until the next 'close', 'revert', or 'quit'.

```bash
open
```

--------------------------------

### Run tests with QEMU/KVM

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Execute tests using QEMU/KVM with a specified disk image. The image is run with a temporary overlay filesystem for safety and parallel execution. This is recommended for tests requiring full system isolation.

```bash
autopkgtest ... -- qemu path/to/image
```

--------------------------------

### Build and Test Local Source Package

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Build a local source package within the virtualization server and then run its tests against the newly built binaries. This is useful for debugging issues that prevent tests from passing.

```bash
autopkgtest packages/mysrc -- virt-server
```

--------------------------------

### Test Built Source Package

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Run tests against a pre-built source package file (.dsc) within the virtualization server. This is similar to building a local source package but uses a specific archive file.

```bash
autopkgtest packages/mysrc_*.dsc -- virt-server
```

--------------------------------

### Test Using Binary .changes File

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Simplify testing by using a binary .changes file from a previous build. This command achieves a similar outcome to testing new binaries with new source but uses a more convenient input format.

```bash
autopkgtest packages/*.changes -- virt-server
```

--------------------------------

### Copy Up Command

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Copies a file or directory from the testbed to the host. Both paths are URL-encoded.

```text
copyup testbed-path host-path
```

--------------------------------

### Revert Testbed Command

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Restores the testbed to its initial state, undoing all changes made. Requires the 'revert' capability.

```text
ok testbed-scratchspace
```

--------------------------------

### Work on Tests with Existing Binaries

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Develop tests incrementally by running them against already built binary packages. This approach avoids waiting for package builds and references local binaries and the current directory as the source.

```bash
autopkgtest -B ../*.deb . -- virt-server
```

--------------------------------

### Run tests directly on the host (null)

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

This option runs tests directly on the host system without virtualization. Be aware that this may leave system clutter and does not support the 'breaks-testbed' restriction.

```bash
autopkgtest ... -- null
```

--------------------------------

### Close Testbed Command

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Stops the testbed and reverts filesystem changes if 'revert' capability is advertised.

```text
ok
```

--------------------------------

### Running the same script with different interpreters

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

Demonstrates using Test-Command to run the same script 'debian/tests/mytest.py' with both 'python' and 'python3' interpreters.

```rst
Test-Command: python debian/tests/mytest.py
```

```rst
Test-Command: python3 debian/tests/mytest.py
```

--------------------------------

### Basic Autopkgtest Command Structure

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

The fundamental structure for invoking autopkgtest, specifying options, source packages, binary packages, and the virtualization server.

```bash
autopkgtest [options] <source package> [<binary package> ...] -- <virt-server> [<virt-server options>]
```

--------------------------------

### Run Tests from Debian Source Package

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Execute tests using the source package directly from the distribution's repositories. This method relies on the \"/etc/apt/sources.list\" configuration for the distribution and release.

```bash
autopkgtest mysrc -- virt-server
```

--------------------------------

### Control file for an inline test command

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

Executes a shell command 'foo-cli --list --verbose' as root, requiring the 'foo' package. Ensures the command exits with zero status.

```rst
Test-Command: foo-cli --list --verbose
Depends: foo
Restrictions: needs-root
```

--------------------------------

### Test New Binaries with New Source (No Rebuild)

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Test updated binary packages with a new source package without rebuilding the source in the virtualization server. This is useful for verifying that existing tests still pass after a package update.

```bash
autopkgtest -B packages/*.deb packages/mysrc_*.dsc -- virt-server
```

--------------------------------

### Copy Down Command

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Copies a file or directory from the host to the testbed. Both paths are URL-encoded.

```text
copydown host-path testbed-path
```

--------------------------------

### Basic debian/tests/control structure

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

Defines three tests (fred, bill, bongo) with dependencies and restrictions. Tests are executed from debian/tests/fred, debian/tests/bill, etc.

```rst
Tests: fred, bill, bongo
Depends: pkg1, pkg2 [amd64] | pkg3 (>= 3)
Restrictions: needs-root, breaks-testbed
```

--------------------------------

### Run Tests from Local Source Tree

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Test using a local source tree while utilizing binary packages from the distribution. This is ideal for developing or fixing tests when the existing binary packages are functional.

```bash
autopkgtest -B packages/mysrc -- virt-server
```

--------------------------------

### Autopkgtest Reboot Test Preparation

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

This snippet shows the conditional logic for preparing and executing a test that involves a system reboot. It handles both continuing a test after a reboot and initiating a reboot sequence.

```bash
        echo "continuing test after reboot"
        ls -l /var/post-request-action
        echo "end of test"
    else
        echo "beginning test"
        /tmp/autopkgtest-reboot-prepare phase1
        touch /var/post-request-action
        reboot
    fi
```

--------------------------------

### Print Execute Command Response

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

Prints a command that can be executed by the caller to run a command on the testbed. The program and arguments are URL-encoded.

```text
ok program,arg,arg... [keyword-info ...]
```

--------------------------------

### Run Tests in a Schroot Environment

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Execute autopkgtest within a specified schroot environment. Schroots provide isolated environments for testing, and mk-sbuild can be used to create them conveniently.

```bash
autopkgtest ... -- schroot schroot-name
```

--------------------------------

### Specify Output Directory for Test Artifacts

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Use the -o or --output-dir option to collect the log file, individual test outputs (stdout/stderr), and any built binaries into a designated directory.

```bash
-o /path/to/test-output/
```

--------------------------------

### Generate Test Summary File

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Use the --summary-file option to direct only the test results (PASS/FAIL) to a specified text file, rather than the standard output.

```bash
--summary-file=/path/to/summary.txt
```

--------------------------------

### Run tests in an LXC container

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Use this command to run tests within a specified LXC container. The -e option is recommended for ephemeral containers to avoid modifications and improve performance.

```bash
autopkgtest ... -- lxc container-name
```

--------------------------------

### Log Complete Autopkgtest Output

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Utilize the -l or --log-file option to capture the entire output of autopkgtest into a specified log file.

```bash
-l /path/to/test.log
```

--------------------------------

### Run tests in a specified chroot

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

Execute tests within a given chroot environment. This requires running autopkgtest as root and lacks automatic cleanup, so ensure you have a separate cleanup mechanism.

```bash
autopkgtest ... -- chroot /path/to/chroot
```

--------------------------------

### Run tests in a chroot tarball using unshare

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.running-tests.rst

This command runs tests within a chroot created using the 'unshare' command, which also handles cleanup. It can be used by a normal user without requiring special host system privileges.

```bash
autopkgtest ... -- unshare
```

--------------------------------

### Decode and Quote Print-Execute-Command Response

Source: https://github.com/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst

A Perl and jq command pipeline to decode a print-execute-command response and quote it for pasting into a shell for manual testing.

```shell
perl -MURI::Escape -ne '$|=1; s{^ok }{}; s/,/\0/g; print uri_unescape $_;' | jq -jrR '. / "\u0000" | @sh + "\n"'
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.