Miroslav Suchý edited this page Feb 21, 2017 · 21 revisions


Mock is a tool for building packages. It can build packages for different architectures and different Fedora, RHEL, and Mageia versions than the build host has. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.

Mock also offers a multi-package tool, mockchain, that can build chains of packages that depend on each other.

Mock is capable of building SRPMs from source configuration management if the mock-scm package is present, then building the SRPM into RPMs. See --scm-enable in the documentation.


Mock is currently being used for all Fedora builds. It is called by Koji and Copr to build chroots and packages.

Release Notes

Tar balls

Tar balls can be found at: https://fedorahosted.org/releases/m/o/mock/


If you want to contribute to code, please checkout https://github.com/rpm-software-management/mock for more informations.

Otherwise just run

dnf install mock


All users that are to use mock must be added to the mock group.

usermod -a -G mock [User name]

:warning: Mock is running some parts of code under root privileges. There are known ways how to get root access once user is in mock group (and once he is able to run mock). This is possible when user abuse the mock configuration options. Please do not add anyone who is not trustworthy to the mock group!

Configuration files are in /etc/mock. Mock versions 0.8.0 and higher cache the downloaded rpm packages (via the yum_cache plugin), which speeds up subsequent builds by a considerable margin. Nevertheless, you may wish to change the default configuration to point to local repositories to speed up builds.

By default, builds are done in /var/lib/mock, so be sure you have room. Starting with mock 0.8.0 and higher, you can change this via the 'basedir' config option.


  • bind_mount - bind mountpoints inside the chroot
  • ccache - compiler cache plugin
  • chroot_scan - allows you to retrieve build artifacts from buildroot (e.g. additional logs, coredumps)
  • compress_logs - compress logs
  • hw_info - prints HW information of builder
  • lvm_root - caching buildroots using LVM
  • mount - allows you to mount directories into chroot
  • package_state - dumps list of available and installed packages
  • pm_request - Executes package manager commands requested by processes runninng in the chroot.
  • root_cache - cache buildroots (as tar file).
  • scm - SCM integration module - builds directly from Git or Svn.
  • selinux - on SELinux enabled box, this plugin will pretend, that SELinux is disabled in build environment.
  • sign - call command on the produced rpm.
  • tmpfs - mount buildroot directory as tmpfs
  • yum_cache - mount /var/cache/yum of your machine to chroot

Plugins can be enabled on command line e.g --enable-plugin=chroot_scan. And you can set plugin options using e.g. --plugin-option=root_cache:age_check=False


One of the reasons why mock has always been quite slow is because installing a lot of packages generates heavy IO load. But the main bottleneck regarding IO is not unpacking files from packages to disk but writing Yum DB entries. Yum DB access (used by both yum and dnf) generates a lot of fsync(2) calls. Those don't really make sense in mock because people generally don't try to recover mock buildroots after hardware failure. We discovered that getting rid of fsync improves the package installation speed by almost a factor of 4. Mikolaj Izdebski developed small C library 'nosync' that is LD_PRELOADed and replaces fsync family of calls with (almost) empty implementations. I added support for it in mock. How to activate it? You need to install nosync package (available in rawhide) and for multilib systems (x86_64) you need version for both architectures. Then it can be enabled in mock by setting

config_opts['nosync'] = True

It is requires those extra steps to set up but it really pays off quickly.

Using Mock outside your git sandbox

Create your SRPM using rpmbuild -bs. Then change to the directory where your srpm was created.

Now you can start mock with

mock -r <configname> rebuild package-1.2-3.src.rpm

where is the name of a configuration from /etc/mock/, without the /etc/mock path prefix and without the .cfg suffix.

Note that you can track the progress of mock using the logs stored in /var/lib/mock/<configfile>/result

Mock inside Docker

Since version 1.3.2 you can run mock inside of Docker. However you need to add SYS_ADMIN to docker container. I.e. run:

docker run --cap-add=SYS_ADMIN ...

:warning: Please note, that Mock inside of Docker skips unsharing of namespace, so it run in the same namespace as other program in the same container. You should not run any other application inside of that container. Mock print warning about this. You can suppress this warning, when you put in config

config_opts['docker_unshare_warning'] = False

Mock on EL 6 and EL 7: Yum, and DNF

Starting with the Fedora 24 builds, Mock requires DNF to run properly. Since not all parts of DNF are available on EL 6 and EL 7, Mock cannot be run there with the default configuration.

There are however two workarounds available:

  • For one time runs it is possible to pass --yum as an option on the command line.
  • To make yum the default package manager, a change in /etc/mock/site-defaults.cfg or inside of any /etc/mock/*.cfg file is necessary:

    config_opts['package_manager'] = 'yum'

For more information, please see the blog entry by Miroslav Suchý.


See separate page: FAQ

Exit codes

Mock have various exist codes to signalize problem in build. See https://github.com/rpm-software-management/mock/blob/master/py/mockbuild/exception.py#L26


List of known issues

If you encounter a bug running mock, please file it in Bugzilla, product "Fedora", component mock (Open Bugs).

If your problem is specific to EPEL, then file it against the "Fedora EPEL" product instead (Open Bugs).

Generate custom config file

Mock main config file is /etc/mock/site-defaults.cfg, which contains all defaults setting and all possible variables you can change. Then you have /etc/mock/<buildroot>.cfg for various buildroots, which contains settings for yum/dnf which are for various distribution different.

When you want to alter the config you may copy one and edit it manually, however if koji is already using such an config, then you can use mock-config --help for information how to generate one. E.g.: koji mock-config --tag f21-build --arch=aarch64 f21

You should not alter site-defaults.cfg unless you want to change settings for all users. You should put your changes to ~/.mock/user.cfg or to ~/.config/mock.cfg.

The order of reading and evaluating configuration files is:

  1. /etc/mock/site-defaults.cfg
  2. /etc/mock/<buildroot>.cfg
  3. ~/.mock/user.cfg
  4. ~/.config/mock.cfg (since mock-1.2.15)

See Also