Difference between revisions of "Installation"

From CRIU
Jump to navigation Jump to search
 
(101 intermediate revisions by 19 users not shown)
Line 1: Line 1:
<code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.
+
<code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to get CRIU binary on your box.
  
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}
+
== Installing from packages ==
  
== Obtaining CRIU Source ==
+
Many distributions provide ready-to-use [[packages]]. If no, or the CRIU version you want is not yet there, you will need to get CRIU sources and compile it.
  
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository]. If you plan to modify CRIU sources the latter way is highly recommended.
+
== Obtaining CRIU sources ==
  
=== Getting source tarball ===
+
You can download the source code as a [https://download.openvz.org/criu/ release tarball] or sync the [https://github.com/checkpoint-restore/criu git repository]. If you plan to modify CRIU sources (e.g. to [[How to submit patches|contribute the code back]]) the latter way is highly recommended. The latest and greatest sources are: {{Latest release}}
{{Out|{{Latest release}}}}
 
  
=== Cloning git repository ===
+
== Installing build dependencies ==
git clone https://github.com/xemul/criu
 
 
 
== Dependencies ==
 
  
 
=== Compiler and C Library ===
 
=== Compiler and C Library ===
  
CRIU is mostly written in C and the build system is based on Makefiles. Thus just install standard <code>gcc</code> and <code>make</code> sets.
+
CRIU is mostly written in C and the build system is based on Makefiles. Thus just install standard <code>gcc</code> and <code>make</code> packages (on Debian use <code>[https://packages.debian.org/build-essential build-essential]</code>).
 
 
Some additional steps are required if you're using Debian.
 
 
 
* For native compilation on Debian based systems, install the <code>build-essential</code> package.
 
* On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.
 
 
 
For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries.
 
 
 
mkdir -p deps/`uname -m`-linux-gnu
 
cd deps
 
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
 
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
 
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz
 
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz
 
cd ..
 
 
 
=== Protocol Buffers with C Bindings ===
 
 
 
CRIU uses the [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] to read and write [[Images]] and thus requires [https://github.com/protobuf-c/protobuf-c C language bindings] to be built. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build and run time, assuming dynamic linking. [[CRIT]] also uses python language bindings of Google Protocol Buffers and requires <code>descriptor.proto</code> from developer files that could be found in <code>protobuf-devel</code> package.
 
 
 
==== Distribution Packages ====
 
The easiest approach for most would be to install distribution packages.
 
 
 
* RPM package names
 
** <code>protobuf</code>
 
** <code>protobuf-c</code>
 
** <code>protobuf-python</code>
 
** <code>protobuf-compiler</code>
 
** <code>protobuf-devel</code>
 
** <code>protobuf-c-devel</code>
 
* Debian package names
 
** <code>protobuf-c-compiler</code>
 
** <code>libprotobuf-c0-dev</code>
 
** <code>protobuf-compiler</code>
 
** <code>protobuf-python</code>
 
 
 
==== Building Protocol Buffers From Source ====
 
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to do <code>autoconf curl g++ libtool</code> first.
 
 
 
To build protobuf
 
 
 
cd deps
 
git clone https://github.com/google/protobuf.git protobuf
 
cd protobuf
 
./autogen.sh
 
./configure --prefix=`pwd`/../`uname -m`-linux-gnu
 
make
 
make install
 
cd ../..
 
 
 
To build protobuf-c
 
 
 
cd deps
 
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c
 
cd protobuf-c
 
./autogen.sh
 
mkdir ../pbc-`uname -m`
 
cd ../pbc-`uname -m`
 
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \
 
  PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig
 
make
 
make install
 
cd ../..
 
 
 
To cross-compile for ARM some more tricks will be required.
 
 
 
For ARMv7
 
 
 
cd deps
 
mkdir -p pbc-arm
 
cd pbc-arm
 
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
cd ../..
 
 
 
For ARM8
 
 
 
cd deps
 
mkdir -p pbc-aarch64
 
cd pbc-aarch64
 
  ../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH
 
cd ../..
 
 
 
=== Other deps ===
 
 
 
* <code>python-ipaddr</code> is used by CRIT to pretty-print ip.
 
* If <code>libbsd</code> available, CRIU will be compiled with setproctitle() support. It will allow to make process titles of service workers to be more verbose.
 
* The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces. The latest one can be cloned from [http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=summary iproute2]. It should be compiled and a path to ip written in the environment variable <code>CR_IP_TOOL</code>.
 
 
 
== Linux Kernel ==
 
  
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.
+
For building with [[32bit tasks C/R]] support you will need <code>libc6-dev-i386, gcc-multilib</code> instead of <code>gcc</code>.
  
=== Configuring the kernel ===
+
[[ARM crosscompile|Cross-compilation for ARM]] is also possible.
  
Most likely the first thing to enable is the <code>CONFIG_EXPERT=y</code> (General setup -> Configure standard kernel features (expert users)) option, which on x86_64 depends on the <code>CONFIG_EMBEDDED=y</code> (General setup -> Embedded system) one (welcome to Kconfig reverse chains hell).
+
=== Protocol Buffers ===
  
The following options must be enabled for CRIU to work:
+
CRIU uses the [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] to read and write [[images]]. The <code>protoc</code> tool is used at build time and CRIU is linked with the <code>libprotobuf-c.so</code>. Also [[CRIT]] uses python  bindings and the <code>descriptor.proto</code> file which typically provided by a distribution's protobuf development package.
  
* ''General setup'' options
+
; RPM packages
** <code>CONFIG_CHECKPOINT_RESTORE=y</code> (Checkpoint/restore support)
+
: <code>protobuf protobuf-c protobuf-c-devel protobuf-compiler protobuf-devel protobuf-python </code>
** <code>CONFIG_NAMESPACES=y</code> (Namespaces support)
 
** <code>CONFIG_UTS_NS=y</code> (Namespaces support -> UTS namespace)
 
** <code>CONFIG_IPC_NS=y</code> (Namespaces support -> IPC namespace)
 
** <code>CONFIG_PID_NS=y</code> (Namespaces support -> PID namespaces)
 
** <code>CONFIG_NET_NS=y</code> (Namespaces support -> Network namespace)
 
** <code>CONFIG_FHANDLE=y</code> (Open by fhandle syscalls)
 
** <code>CONFIG_EVENTFD=y</code> (Enable eventfd() system call)
 
** <code>CONFIG_EPOLL=y</code> (Enable eventpoll support)
 
* ''Networking support -> Networking options'' options for sock-diag subsystem
 
** <code>CONFIG_UNIX_DIAG=y</code> (Unix domain sockets -> UNIX: socket monitoring interface)
 
** <code>CONFIG_INET_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface)
 
** <code>CONFIG_INET_UDP_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface)
 
** <code>CONFIG_PACKET_DIAG=y</code> (Packet socket -> Packet: sockets monitoring interface)
 
** <code>CONFIG_NETLINK_DIAG=y</code> (Netlink socket -> Netlink: sockets monitoring interface)
 
* Other options
 
** <code>CONFIG_INOTIFY_USER=y</code> (File systems -> Inotify support for userspace)
 
** <code>CONFIG_IA32_EMULATION=y</code> (x86 only) (Executable file formats -> Emulations -> IA32 Emulation)
 
  
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable the <code>CONFIG_MEM_SOFT_DIRTY=y</code> (optional) (Processor type and features -> Track memory changes).
+
; Deb packages
 +
: <code>libprotobuf-dev libprotobuf-c-dev protobuf-c-compiler protobuf-compiler python3-protobuf</code>
  
== Building CRIU From Source ==
+
Optionally, you may [[build protobuf]] from sources.
  
=== Native Compilation ===
+
=== Other stuff ===
Simply run <code>make</code> in the CRIU source directory.
 
  
=== Compilation in Docker container ===
+
* <code>pkg-config</code> to check on build library dependencies.
 +
* <code>python-ipaddress</code> is used by CRIT to pretty-print IP addresses and is also required by zdtm.py
 +
* <code>libbsd-devel</code> (RPM) / <code>libbsd-dev</code> (DEB) If available, CRIU will be compiled  with <code>setproctitle()</code> support and set verbose process titles on service workers.
 +
* <code>iproute2</code> version 3.5.0 or higher is needed for dumping network namespaces. The latest one can be cloned from [http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=summary iproute2]. It should be compiled and a path to ip set as the [[environment variables|<code>CR_IP_TOOL</code> variable]]
 +
* <code>nftables</code> (RPM) / <code>libnftables-dev</code> (DEB) If available, CRIU will be compiled with nftables C/R support
 +
* <code>libcap-devel</code> (RPM) / <code>libcap-dev</code> (DEB) - Require
 +
* <code>libnet-devel libnl3-devel</code> (RPM) / <code>libnet1-dev</code> (DEB) / <code>libnl-3-dev libnet-dev</code> (Ubuntu) - Require
 +
* <code>libaio-devel</code> (RPM) / <code>libaio-dev</code> (DEB) is needed to run tests
 +
* <code>gnutls-devel</code> (RPM) / <code>libgnutls28-dev</code> (DEB), if available, CRIU will be compiled with [[TLS]] support
 +
* <code>python2-future</code> or <code>python3-future</code> is now needed for zdtm.py tests launcher
 +
* <code>libdrm-devel</code> (RPM) / <code>libdrm-dev</code> (DEB) If available, CRIU will be compiled with support for AMD GPUs.
  
There's a <code>docker-build</code> target in Makefile which builds CRIU in Ubuntu Docker container. Just run
+
For APT use the <code>--no-install-recommends</code> parameter is to avoid asciidoc pulling in a lot of dependencies.
 +
Also read about [[ZDTM test suite]] if you will run CRIU tests, those sources need other deps.
  
make docker-build
+
== Building the tool ==
  
and that's it.
+
Simply run <code>make</code> in the CRIU source directory. This is the standard way, but there are some options available.
  
=== Compilation with non-standard paths to dependencies ===
+
# There's a ''docker-build'' target in Makefile which builds CRIU in Ubuntu Docker container. Just run <code>make docker-build</code> and that's it.
 +
# CRIU has functionality that is either optional or behaves differently depending on the kernel CRIU is running on. By default build process includes maximum of it, but this behavior [[configuring|can be changed]].
 +
# You may [[Manual build deps|specify build dependencies by hands]]
  
Here is an example of building natively specifying manually built dependencies.
+
== Installing ==
  
cd deps
+
CRIU works perfectly even when run from the sources directory (with the <code>./criu/criu</code> command), but if you want to have in standard paths run <code>make install</code>. You may need to install <code>asciidoc</code> and <code>xmlto</code> packages to make install-man work.
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`
 
cd criu-`uname -m`
 
make \
 
  USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \
 
  PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"
 
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check
 
cd ../..
 
 
 
=== Cross Compilation for ARM ===
 
 
 
;ARMv7
 
 
 
cd deps
 
rsync -a --exclude=.git --exclude=deps .. criu-arm
 
cd criu-arm
 
make \
 
  ARCH=arm \
 
  CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/arm-linux-gnueabihf- \
 
  USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \
 
  PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"
 
cd ../..
 
 
 
;ARMv8
 
 
 
  cd deps
 
  rsync -a --exclude=.git --exclude=deps .. criu-aarch64
 
  cd criu-aarch64
 
  make \
 
  ARCH=aarch64 \
 
  CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/aarch64-linux-gnu- \
 
  USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \
 
  PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"
 
  cd ../..
 
 
 
== Installation ==
 
CRIU works perfectly even when run from the sources directory (with the "./criu" command), but if you want to have in standard paths run
 
<pre>
 
# make install
 
</pre>
 
  
 
== Checking That It Works ==
 
== Checking That It Works ==
  
First thing to do is to run
+
Linux kernel v3.11 or newer is required, with some specific config options turned on. Various advanced CRIU features might require even newer kernel.  So the first thing to do is to [[Checking the kernel|check the kernel]] by running <code>criu check</code>. At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing. If your distribution does not provide needed kernel, you might want to [[Linux kernel|compile one yourself]].
 
 
<pre>
 
# criu check --ms
 
</pre>
 
 
 
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.
 
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would
 
check for ''all'' the kernel features to work.
 
  
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.
+
You can then try running the [[ZDTM Test Suite]] which sits in the <code>test/zdtm/</code> directory.
  
 
== Further reading ==
 
== Further reading ==
  
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].
+
* [[Usage]]
 +
* [[Advanced usage]]
 +
* [[:Category:HOWTO]]
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
 +
[[Category:Editor help needed]]

Latest revision as of 01:56, 30 September 2023

criu is an utility to checkpoint/restore a process tree. This page describes how to get CRIU binary on your box.

Installing from packages[edit]

Many distributions provide ready-to-use packages. If no, or the CRIU version you want is not yet there, you will need to get CRIU sources and compile it.

Obtaining CRIU sources[edit]

You can download the source code as a release tarball or sync the git repository. If you plan to modify CRIU sources (e.g. to contribute the code back) the latter way is highly recommended. The latest and greatest sources are:

Tarball: criu-4.0.tar.gz
Version: 4.0 "CRIUDA"
Released: 20 Sep 2024
GIT tag: v4.0

Installing build dependencies[edit]

Compiler and C Library[edit]

CRIU is mostly written in C and the build system is based on Makefiles. Thus just install standard gcc and make packages (on Debian use build-essential).

For building with 32bit tasks C/R support you will need libc6-dev-i386, gcc-multilib instead of gcc.

Cross-compilation for ARM is also possible.

Protocol Buffers[edit]

CRIU uses the Google Protocol Buffers to read and write images. The protoc tool is used at build time and CRIU is linked with the libprotobuf-c.so. Also CRIT uses python bindings and the descriptor.proto file which typically provided by a distribution's protobuf development package.

RPM packages
protobuf protobuf-c protobuf-c-devel protobuf-compiler protobuf-devel protobuf-python
Deb packages
libprotobuf-dev libprotobuf-c-dev protobuf-c-compiler protobuf-compiler python3-protobuf

Optionally, you may build protobuf from sources.

Other stuff[edit]

  • pkg-config to check on build library dependencies.
  • python-ipaddress is used by CRIT to pretty-print IP addresses and is also required by zdtm.py
  • libbsd-devel (RPM) / libbsd-dev (DEB) If available, CRIU will be compiled with setproctitle() support and set verbose process titles on service workers.
  • iproute2 version 3.5.0 or higher is needed for dumping network namespaces. The latest one can be cloned from iproute2. It should be compiled and a path to ip set as the CR_IP_TOOL variable
  • nftables (RPM) / libnftables-dev (DEB) If available, CRIU will be compiled with nftables C/R support
  • libcap-devel (RPM) / libcap-dev (DEB) - Require
  • libnet-devel libnl3-devel (RPM) / libnet1-dev (DEB) / libnl-3-dev libnet-dev (Ubuntu) - Require
  • libaio-devel (RPM) / libaio-dev (DEB) is needed to run tests
  • gnutls-devel (RPM) / libgnutls28-dev (DEB), if available, CRIU will be compiled with TLS support
  • python2-future or python3-future is now needed for zdtm.py tests launcher
  • libdrm-devel (RPM) / libdrm-dev (DEB) If available, CRIU will be compiled with support for AMD GPUs.

For APT use the --no-install-recommends parameter is to avoid asciidoc pulling in a lot of dependencies. Also read about ZDTM test suite if you will run CRIU tests, those sources need other deps.

Building the tool[edit]

Simply run make in the CRIU source directory. This is the standard way, but there are some options available.

  1. There's a docker-build target in Makefile which builds CRIU in Ubuntu Docker container. Just run make docker-build and that's it.
  2. CRIU has functionality that is either optional or behaves differently depending on the kernel CRIU is running on. By default build process includes maximum of it, but this behavior can be changed.
  3. You may specify build dependencies by hands

Installing[edit]

CRIU works perfectly even when run from the sources directory (with the ./criu/criu command), but if you want to have in standard paths run make install. You may need to install asciidoc and xmlto packages to make install-man work.

Checking That It Works[edit]

Linux kernel v3.11 or newer is required, with some specific config options turned on. Various advanced CRIU features might require even newer kernel. So the first thing to do is to check the kernel by running criu check. At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing. If your distribution does not provide needed kernel, you might want to compile one yourself.

You can then try running the ZDTM Test Suite which sits in the test/zdtm/ directory.

Further reading[edit]