Hasher/vm-run: различия между версиями
Vt (обсуждение | вклад) Нет описания правки |
Vt (обсуждение | вклад) м (→debug) |
||
(не показано 12 промежуточных версий этого же участника) | |||
Строка 19: | Строка 19: | ||
vm-run "''команды запуска тестов...''" | vm-run "''команды запуска тестов...''" | ||
Если тяжелые тесты имеет смысл запускать только | Если тяжелые тесты имеет смысл запускать только под KVM и не запускать под эмуляцией, то следует использовать опцию <tt>--kvm=cond</tt>, она работает более надежно чем проверка <tt>[ -w /dev/kvm ]</tt>. В случае, если поддержка KVM не будет обнаружена <tt>vm-run --kvm=cond</tt> не запустит команду, но завершится успешно: | ||
%check | %check | ||
vm-run --kvm=cond make check | |||
=== Включение kvm === | === Включение kvm === | ||
Для ускорения работы тестов полезно настроить kvm в hasher | Для ускорения работы тестов полезно настроить kvm в hasher. Поддержка kvm есть на всех основых архитектурах. | ||
'''A''': Помимо того, что в системе должен быть загружен соответствующий вашей архитектуре kvm модуль (например, kvm-intel), необходимо ещё выполнить следующие '''два''' [https://lists.altlinux.org/pipermail/devel/2019-October/208630.html условия]: | |||
* В {{path|/etc/hasher-priv/system}} нужно добавить <tt>/dev/kvm</tt> в <tt>allowed_devices=</tt>, например: | |||
allowed_mountpoints=/proc,/dev/pts,/dev/shm | |||
allowed_devices=/dev/kvm | |||
* В {{path|~/.hasher/config}} добавить <tt>/dev/kvm</tt> в <tt>known_mountpoints=</tt>, например: | |||
known_mountpoints=/proc,/dev/pts,/dev/kvm | |||
* Если нужно зайти в <tt>hasher</tt> интерактивно, то добавляется '''третье''' условие — при запуске <tt>hsh-shell</tt> нужно передать <tt>/dev/kvm</tt> в ключ <code>--mountpoints=</code>, пример: | |||
$ hsh-shell --mountpoints=/proc,/dev/pts,/dev/kvm | |||
= Советы по использованию = | |||
С версии 1.57-alt1 по умолчанию команды передаваемые в vm-run выполняются под <code>set -xe</code>. То есть самому <code>set -xe</code> можно не делать. | |||
== ext4 == | |||
По умолчанию исходная файловая система пробрасывается по 9p (9pfs) на которой могут работать не все ожидаемые тестами возможности файловых систем или нет доступа на запись вне <code>$HOME</code>. Поэтому можно автоматически сгенерировать образ ext4 со всеми файлами. Два варианта: | |||
1. Образ сгенерируется под пользователем rooter при создании сборочной среды (так что там может быть не все что вы ожидаете): | |||
BuildRequires: rpm-build-vm-createimage | |||
и при запуске передать флаг <code>--rootfs</code>: | |||
vm-run --rootfs ''команды'' | |||
2. Образ генерируется под builder во время запуска - <code>BuildRequires: rpm-build-vm</code> как обычно, а при запуске передать флаг <code>--ext4</code>: | |||
vm-run --ext4 ''команды'' | |||
В обоих случая имя образа <code>/tmp/vm-ext4.img</code>, а отображение исходной файловой системы по 9p будет примонтировано в <code>/mnt/9p</code>. | |||
== sbin, user, sudo, udevd == | |||
* Если в PATH нужен /sbin:/usr/sbin поможет опция <code>--sbin</code>. | |||
* Если для работы тестов нужно <code>sudo</code>, то есть fake sudo, которое включается опцией <code>--sudo</code>. (Пакет sudo для этого ставить не нужно.) | |||
* Если запуск должен начинаться не под root, а под builder - есть опция <code>--user</code>. (Что автоматически добавляет sudo.) Некоторые тесты могут рассчитывать на работу под пользователем, а запускать рутовые команды через sudo. | |||
* Можно автоматически запустить udevd опцией <code>--udevd</code>. | |||
== here-document == | |||
Если скрипт многострочный, то можно его запускать параметр командной строки в кавычках, а как here-document: | |||
vm-run --heredoc <<EOF | |||
''команды..'' | |||
EOF | |||
== debug == | |||
При отладке можно быть полезно (но не нужно вставлять в spec): | |||
* Включение максимального логирования загрузки ядра: <code>--loglevel=max</code>. | |||
* Включение логирования процесса initrd: <code>--append=rddebug</code> или <code>--loglevel=debug</code> включит и максимальный лог ядра и rddebug. | |||
* Если rootfs не смонтировалось, можно попасть в shell в initrd: <code>BuildRequires: busybox</code> и запуск с опцией <code>--rdshell</code>. В этом случае после окончания монтирования rootfs (или по ошибке) и до switch root запустится busybox sh. Может пригодиться добавить в initrd дополнительный модуль опцией <code>--modules=</code> (зависимости определятся автоматически) или любой файл опцией <code>--rdadd=</code> (это можно делать много раз). | |||
{{Category navigation|title=hasher|category=hasher|sortkey={{SUBPAGENAME}}}} | {{Category navigation|title=hasher|category=hasher|sortkey={{SUBPAGENAME}}}} |
Текущая версия от 16:49, 23 октября 2023
Иногда для запуска тестов в секции %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, udevd
- Если в PATH нужен /sbin:/usr/sbin поможет опция
--sbin
. - Если для работы тестов нужно
sudo
, то есть fake sudo, которое включается опцией--sudo
. (Пакет sudo для этого ставить не нужно.) - Если запуск должен начинаться не под root, а под builder - есть опция
--user
. (Что автоматически добавляет sudo.) Некоторые тесты могут рассчитывать на работу под пользователем, а запускать рутовые команды через sudo. - Можно автоматически запустить udevd опцией
--udevd
.
here-document
Если скрипт многострочный, то можно его запускать параметр командной строки в кавычках, а как here-document:
vm-run --heredoc <<EOF команды.. EOF
debug
При отладке можно быть полезно (но не нужно вставлять в spec):
- Включение максимального логирования загрузки ядра:
--loglevel=max
. - Включение логирования процесса initrd:
--append=rddebug
или--loglevel=debug
включит и максимальный лог ядра и rddebug. - Если rootfs не смонтировалось, можно попасть в shell в initrd:
BuildRequires: busybox
и запуск с опцией--rdshell
. В этом случае после окончания монтирования rootfs (или по ошибке) и до switch root запустится busybox sh. Может пригодиться добавить в initrd дополнительный модуль опцией--modules=
(зависимости определятся автоматически) или любой файл опцией--rdadd=
(это можно делать много раз).