Hasher/vm-run: различия между версиями

Материал из ALT Linux Wiki
 
(не показано 5 промежуточных версий этого же участника)
Строка 39: Строка 39:


= Советы по использованию =
= Советы по использованию =
С версии 1.57-alt1 по умолчанию команды передаваемые в vm-run выполняются под <code>set -xe</code>. То есть самому <code>set -xe</code> можно не делать.
== ext4 ==
== ext4 ==
По умолчанию исходная файловая система пробрасывается по 9p (9pfs) на которой могут работать не все ожидаемые тестами возможности файловых систем или нет доступа на запись вне <code>$HOME</code>. Поэтому можно автоматически сгенерировать образ ext4 со всеми файлами. Два варианта:
По умолчанию исходная файловая система пробрасывается по 9p (9pfs) на которой могут работать не все ожидаемые тестами возможности файловых систем или нет доступа на запись вне <code>$HOME</code>. Поэтому можно автоматически сгенерировать образ ext4 со всеми файлами. Два варианта:
Строка 50: Строка 52:
В обоих случая имя образа <code>/tmp/vm-ext4.img</code>, а отображение исходной файловой системы по 9p будет примонтировано в <code>/mnt/9p</code>.
В обоих случая имя образа <code>/tmp/vm-ext4.img</code>, а отображение исходной файловой системы по 9p будет примонтировано в <code>/mnt/9p</code>.


== sbin, user, sudo ==
== sbin, user, sudo, udevd ==
* Если в PATH нежен /sbin:/usr/sbin поможет опция <code>--sbin</code.
* Если в PATH нужен /sbin:/usr/sbin поможет опция <code>--sbin</code>.
* Если для работы тестов нужно <code>sudo</code>, то есть fake sudo, которое включается опцией <code>--sudo</code>. (Пакет sudo для этого ставить не нужно.)
* Если для работы тестов нужно <code>sudo</code>, то есть fake sudo, которое включается опцией <code>--sudo</code>. (Пакет sudo для этого ставить не нужно.)
* Если запуск должен начинаться не под root, а под builder - есть опция <code>--user</code>. (Что автоматически добавляет sudo.) Некоторые тесты могут рассчитывать на работу под пользователем, а запускать рутовые команды через 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}}}}

Текущая версия от 19: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= (это можно делать много раз).