Hasher/vm-run

Иногда для запуска тестов в секции %check требуются рутовые привилегии, чтоб обойти это ограничение есть пакет rpm-build-vm (анонс), который позволяет запустить произвольную команду под qemu с псевдо-рутовыми привилегиями.

Он работает по аналогии с virtme, eudyptula-boot, vido и т.д. — бутится Linux ядро, где корень файловой системы (то есть содержимое hasher) предоставлен внутрь qemu по протоколу 9p, а init запускает вашу команду. Нужно учитывать, что хоть внутри виртуализации у вас будут рутовые привилегии, но снаружи будет обычный юзер builder. Если для тестов надо создавать файлы под рутом, то можно использовать tmpfs или создать ext4 образ в файле и примонтировать его куда требуется. Код возврата вашей команды вернется из vm-run.

Справка по возможностям: vm-run --help.

Пример, что добавить в spec для обычного user space пакета (не ядра и не модуля ядра) для запуска make check под рутом:

 BuildRequires: rpm-build-vm
 ...
 %check
 vm-run make check

Установка rpm-build-vm автоматически доставляет ядро kernel-image-un-def в hasher, что будет излишне при сборке ядра или ядерного модуля, поэтому есть пакет rpm-build-vm-run, который не имеет зависимостей к ядру. Пример использования для ядра или модуля:

 BuildRequires: rpm-build-vm-run
 ...
 %check
 vm-run "команды запуска тестов..."

Если тяжелые тесты имеет смысл запускать только под KVM и не запускать под эмуляцией, то следует использовать опцию --kvm=cond, она работает более надежно чем проверка [ -w /dev/kvm ]. В случае, если поддержка KVM не будет обнаружена vm-run --kvm=cond не запустит команду, но завершится успешно:

 %check
 vm-run --kvm=cond make check

Включение kvm

Для ускорения работы тестов полезно настроить kvm в hasher. Поддержка kvm есть на всех основых архитектурах.

A: Помимо того, что в системе должен быть загружен соответствующий вашей архитектуре kvm модуль (например, kvm-intel), необходимо ещё выполнить следующие два условия:

• В /etc/hasher-priv/system нужно добавить /dev/kvm в allowed_devices=, например:

 allowed_mountpoints=/proc,/dev/pts,/dev/shm
 allowed_devices=/dev/kvm

• В ~/.hasher/config добавить /dev/kvm в known_mountpoints=, например:

 known_mountpoints=/proc,/dev/pts,/dev/kvm

• Если нужно зайти в hasher интерактивно, то добавляется третье условие — при запуске hsh-shell нужно передать /dev/kvm в ключ --mountpoints=, пример:

 $ hsh-shell --mountpoints=/proc,/dev/pts,/dev/kvm

Советы по использованию

С версии 1.57-alt1 по умолчанию команды передаваемые в vm-run выполняются под set -xe. То есть set -xe можно не делать.

ext4

По умолчанию исходная файловая система пробрасывается по 9p (9pfs) на которой могут работать не все ожидаемые тестами возможности файловых систем или нет доступа на запись вне $HOME. Поэтому можно автоматически сгенерировать образ ext4 со всеми файлами. Два варианта:

1. Образ сгенерируется под пользователем rooter при создании сборочной среды (так что там может быть не все что вы ожидаете):

 BuildRequires: rpm-build-vm-createimage

и при запуске передать флаг --rootfs:

 vm-run --rootfs команды

2. Образ генерируется под builder во время запуска - BuildRequires: rpm-build-vm как обычно, а при запуске передать флаг --ext4:

 vm-run --ext4 команды

В обоих случая имя образа /tmp/vm-ext4.img, а отображение исходной файловой системы по 9p будет примонтировано в /mnt/9p.

sbin, user, sudo

• Если в PATH нужен /sbin:/usr/sbin поможет опция --sbin.
• Если для работы тестов нужно sudo, то есть fake sudo, которое включается опцией --sudo. (Пакет sudo для этого ставить не нужно.)
• Если запуск должен начинаться не под root, а под builder - есть опция --user. (Что автоматически добавляет sudo.) Некоторые тесты могут рассчитывать на работу под пользователем, а запускать рутовые команды через sudo.

here-document

Если скрипт многострочный, то можно его запускать параметр командной строки в кавычках, а как here-document:

 vm-run --heredoc <<EOF
 команды..
 EOF