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

Материал из ALT Linux Wiki
(→‎Q5: про сборку в girar пакета без Packager)
(не показаны 32 промежуточные версии 9 участников)
Строка 1: Строка 1:
__NOTOC__
== При запуске <tt>hsh</tt> я получаю ошибку: <code>hsh-mkchroot: cannot access getugid1 helper</code> ==
== Q1 ==
 
Q: При запуске <tt>hsh</tt> я получаю ошибку
hsh-mkchroot: cannot access getugid1 helper.


A: [[Руководство по hasher#Добавление пользователя|Добавьте себя в hasher]].
A: [[Руководство по hasher#Добавление пользователя|Добавьте себя в hasher]].


== Q2 ==
== Я добавил себя в <tt>hasher</tt>, но всё равно получаю ошибку <code>hsh: /usr/libexec/hasher-priv/getconf.sh: cannot access getconf helper</code> ==
 
Q: Я добавил себя в <tt>hasher</tt>, но всё равно получаю ошибку
hsh: /usr/libexec/hasher-priv/getconf.sh: cannot access getconf helper.


A: Перелогиньтесь — <tt>hasher-useradd</tt> добавляет пользователя в новые группы.
A: Перелогиньтесь — <tt>hasher-useradd</tt> добавляет пользователя в новые группы.


== Q3 ==
== В моём <tt>hasher</tt> собираются пакеты со странной архитектурой, которые не ставятся ==
 
Q: Я собираю пакет, но он ломается из-за того, что в сборочной среде нет <tt>/proc</tt>.
 
A: [[Руководство по hasher#Монтирование /proc|Настройте монтирование /proc]].
 
== Q4 ==
 
Q: В моём <tt>hasher</tt> собираются пакеты со странной архитектурой, которые не ставятся.


A: [[Руководство по hasher#Архитектура пакетов|Явно укажите архитектуру сборки]].
A: [[Руководство по hasher#Архитектура пакетов|Явно укажите архитектуру сборки]].


== Q5 ==
== В конце сборки в <tt>hasher</tt> выдаются ошибки вида <code>some-packet.src.rpm: wrong PACKAGER</code> ==


Q: В конце сборки в <tt>hasher</tt> выдаются ошибки вида
Q: В конце сборки в <tt>hasher</tt> выдаются ошибки вида
Строка 33: Строка 18:
A1: Эти ошибки выдаются утилитой [[sisyphus_check]], проверяющей соответствие пакетов правилам репозитория [[Sisyphus]]. Исправьте ошибки в spec-файле (обычно добавлением корректного тега <tt>Packager</tt>).
A1: Эти ошибки выдаются утилитой [[sisyphus_check]], проверяющей соответствие пакетов правилам репозитория [[Sisyphus]]. Исправьте ошибки в spec-файле (обычно добавлением корректного тега <tt>Packager</tt>).


В частности, отсутствие тега <tt>Packager</tt> в spec-файле обычно (если не сделаны настройки, описанные в ответах ниже) приводит к такому результату (потому что в собранном пакете в качестве <tt>Packager</tt> будет некое значение по умолчанию.
В частности, отсутствие тега <tt>Packager</tt> в spec-файле обычно (если не сделаны настройки, описанные в ответах ниже) приводит к такому результату (потому что в собранном пакете в качестве <tt>Packager</tt> будет некое значение по умолчанию).


Однако, если такой пакет без тега <tt>Packager</tt> будет собираться в [[girar]] (например, том, который работает на [[git.alt]]), то эта проверка будет успешно пройдена, потому что[http://lists.altlinux.org/pipermail/devel/2009-February/167112.html]: "girar builder, собирая пакет из подписанного git-тэга, указывает в качестве packager'а по умолчанию имя подписавшего git-тэг, поэтому, если поле Packager в спек-файле отсутствует, packager'ом собранного пакета окажется тот, кто подписал git-тэг." По правилам ALT это повлечёт назначение ответственным за пакет (maintainer'ом) нового packager'а (где это записано? так ли это?). Возможно, это не то, чего Вы хотели бы.
Однако, если такой пакет без тега <tt>Packager</tt> будет собираться в [[girar]] (например, том, который работает на [[git.alt]]), то эта проверка будет успешно пройдена, потому что[http://lists.altlinux.org/pipermail/devel/2009-February/167112.html]: "girar builder, собирая пакет из подписанного git-тэга, указывает в качестве packager'а по умолчанию имя подписавшего git-тэг, поэтому, если поле Packager в спек-файле отсутствует, packager'ом собранного пакета окажется тот, кто подписал git-тэг." По правилам ALT это повлечёт назначение ответственным за пакет (maintainer'ом) нового packager'а (где это записано? так ли это?). Возможно, это не то, чего Вы хотели бы.


A2: Если пакет не предназначен для Sisyphus и выдаваемые ошибки связаны не с техническими проблемами в пакете, а с невыполнением политик репозитория (например, ограничение на тэг <tt>Packager</tt> и на PGP-подпись) — [[Руководство по hasher#Отключение проверок sisyphus_check|отключите часть проверок <tt>sisyphus_check</tt>]]; [http://lists.altlinux.org/pipermail/devel-newbies/2012-September/000836.html можно добавить] в {{path|~/.hasher/config}}:
A2: Если пакет не предназначен для Sisyphus и выдаваемые ошибки связаны не с техническими проблемами в пакете, а с невыполнением политик репозитория (например, ограничение на тэг <tt>Packager</tt> и на PGP-подпись; возможно, будет интересна {{altbug|15376}}) — [[Руководство по hasher#Отключение проверок sisyphus_check|отключите часть проверок <tt>sisyphus_check</tt>]]; [http://lists.altlinux.org/pipermail/devel-newbies/2012-September/000836.html можно добавить] в {{path|~/.hasher/config}}:
  no_sisyphus_check="packager,buildhost,gpg"
  no_sisyphus_check="packager,buildhost,gpg"


Строка 46: Строка 31:
  $ gear -v --hasher -- hsh --target=i586 --packager="Andrew Clark <andyc@altlinux.org>" ~/hasher
  $ gear -v --hasher -- hsh --target=i586 --packager="Andrew Clark <andyc@altlinux.org>" ~/hasher


== Q6 ==
A5: Если пакет собирать в локальном <tt>hasher</tt>-е и поле <tt>Packager</tt> содержит email не из домена altlinux, то возникнет схожая ошибка в модуле проверки changelog-а <tt>sisyphus_check</tt>. Так же как и с проверкой packager, можно добавить в no_sisyphus_check=changelog.
 
== При запуске <tt>hsh</tt> я получаю ошибку <code>hasher-priv: /path/to/workdir/chroot: prefix mismatch</code> ==


Q: При запуске <tt>hsh</tt> я получаю ошибку
Q: При запуске <tt>hsh</tt> я получаю ошибку
Строка 56: Строка 43:
A: По умолчанию <tt>hasher</tt> позволяет располагать свою рабочую директорию в <tt>$HOME</tt> пользователя или в <tt>/tmp/.private</tt>. Или измените место, где создаётся рабочая директория, или разрешите дополнительные директории с помощью ключа <tt>prefix</tt> в <tt>/etc/hasher-priv/system</tt> (общесистемно) или <tt>/etc/hasher-priv/user.d/<USER></tt> (для одного пользователя).
A: По умолчанию <tt>hasher</tt> позволяет располагать свою рабочую директорию в <tt>$HOME</tt> пользователя или в <tt>/tmp/.private</tt>. Или измените место, где создаётся рабочая директория, или разрешите дополнительные директории с помощью ключа <tt>prefix</tt> в <tt>/etc/hasher-priv/system</tt> (общесистемно) или <tt>/etc/hasher-priv/user.d/<USER></tt> (для одного пользователя).


== Q7 ==
== hsh не запускается, /.host/entry: No such file or directory ==


Q: При запуске <tt>hsh</tt> выдаёт ошибку:
Q: При запуске <tt>hsh</tt> выдаёт ошибку:
Строка 65: Строка 52:
и еще раз повторите запуск <tt>hsh</tt>.
и еще раз повторите запуск <tt>hsh</tt>.


== Q8 ==
== mkimage останавливается и чего-то ждёт ==


Q: Сборка дистрибутива останавливается на таких вот строчках:
Q: Сборка дистрибутива останавливается на таких вот строчках:
Строка 78: Строка 65:
и еще раз повторите запуск <tt>hsh</tt>.
и еще раз повторите запуск <tt>hsh</tt>.


== Q9 ==
== При запуске <tt>hsh</tt> выдаёт ошибку: <code>hasher-priv: openpty: No such file or directory</code> ==
 
Q: При запуске <tt>hsh</tt> выдаёт ошибку:
hasher-priv: openpty: No such file or directory


A: Проверьте, что у вас смонтирован <tt>/dev/pts</tt> на хост-системе.
A: Проверьте, что у вас смонтирован <tt>/dev/pts</tt> на хост-системе.


== Q10 ==
== hsh не запускается: /dev/null: Permission denied ==


Q: При запуске <tt>hsh</tt> выдаёт ошибку:
Q: При запуске <tt>hsh</tt> выдаёт ошибку:
Строка 96: Строка 80:
  tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=3145728k)
  tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=3145728k)


== Q11 ==
== почему hasher перестал создавать хэши ({{path|base/*}}) для своего репозитория? ==
 
A: потому что для некоторого ускорения сборки они [http://lists.altlinux.org/pipermail/devel/2009-December/178354.html упразднены] в пользу непосредственного сканирования каталога (<tt>rpm-dir</tt> вместо <tt>rpm</tt> в {{path|sources.list}}).  Для создания хэшей при их публикации придётся запустить {{cmd|$hasher/aptbox/regenbasedir}} (или {{cmd|genbasedir --bloat}} совсем вручную).
 
<div id="virus"></div>
== правда, что Hasher — это вирус под Linux? ==
 
A: действительно, существует [http://en.wikipedia.org/wiki/Linux_malware#Viruses ELF-вирус] [http://vxheavens.com/lib/vhe02.html Linux.Hasher], но в отличие от него — наличие технических механизмов заражения и саморазмножения в обсуждаемом hasher не показано.
 
== Как кешировать и не скачивать одно и то же по многу раз для сборки разных пакетов? ==
 
Q: [http://lists.altlinux.org/pipermail/sisyphus/2008-June/331276.html Yury Aliaev]: "чтобы не скачивать одно и то же по многу раз для сборки разных пакетов, необходимо, чтобы скачанные пакеты где-то хранились и при следующем запуске брались уже из этого места. Опять-таки, если пакет в Сизифе более свежий, чем локально скачанный, то скачанный пакет должен обновиться на более свежий."
 
A: Можно добавить от себя в конфигурацию apt-а для hasher особое место для кэша apt, которое не будет чиститься hsh; например, общесистемный /var/cache/apt/archives/ -- см. [[Hasher/Tips#Кэширование скачиваемых apt-ом пакетов]].
 
== процесс виснет на этапе какой-то установки пакетов через apt ==
 
Q: При запуске hsh с настройками apt по умолчанию (основанными на общесистемных /etc/apt/) процесс виснет на этапе какой-то установки пакетов через apt (при применении опции -v -- на сообщении "... пакеты будут установлены:" и список пакетов дальше).
 
A: Может быть, в /etc/apt/sources.list, /etc/apt/sources.list.d/* есть источник-cdrom. (Например, у меня cdrom был прописан в /etc/apt/sources.list.d/sources.list -- я удалил этот файл, и больше hsh не зависает на этом этапе. Примечание: я запускаю вообще-то {{cmd|gear-hsh -v -- -v}}, а не чистый hsh.)
 
Ответ найден благодаря сообщениям
* [http://lists.altlinux.org/pipermail/devel/2007-June/140523.html "Оказалось, что в /etc/apt/sources.list.d/sources.list был прописан cdrom, и hasher просил его вставить"],
* [http://lists.altlinux.org/pipermail/devel/2008-August/158438.html "&lt;apt&gt; спрашивает что же ему выбрать, а хешер ему не отвечает. --Вообще он этого делать не должен.  Покажите вывод hsh -v в районе затыка. --Причина оказалась в том, что &lt;...&gt; apt пытался взять его с CDROM."]
 
== как передать параметры сборки {{cmd|rpm}}, например, <tt>--enable</tt> или <tt>--without</tt>? ==
 
A: <tt>--build-args</tt> для {{cmd|hsh}} или {{cmd|gear-hsh}}; при пересборке src.rpm также [http://lists.altlinux.org/pipermail/sisyphus/2005-April/277314.html следует] добавить <tt>--repackage-source</tt>:
 
hsh --build-args "--enable static" --repackage-source нужный.src.rpm
gear-hsh --build-args "--enable static"
 
== «<tt>Пакет setup присутствует в базе данных, но не имеет доступной версии.</tt> […]» ==
 
Q: отчего при работающем {{path|sources.list}} хэшер может жаловаться: «<tt>Пакет setup присутствует в базе данных, но не имеет доступной версии.</tt> […] <tt>E: Для пакета setup не найдено подходящего кандидата для установки</tt>»?
 
A: [http://lists.altlinux.org/pipermail/community/2015-April/683972.html проверьте], нет ли забытого указания архитектуры по умолчанию в {{path|~/.hasher/config}} или {{path|~/.rpmrc}}.
 
== как обеспечить попадание в hasher chroot именно нужного варианта {{pkg|branding-*-release}}? ==
 
Q: как обеспечить попадание в hasher chroot именно нужного варианта {{pkg|branding-*-release}}?  Получаю либо {{pkg|branding-sisyphus-server-light-release}}, либо конфликт запрошенного с ним:
error: failed dependencies:
        branding-sisyphus-server-light-release conflicts
with branding-altlinux-centaurus-release-7.0.5-alt1
hsh-initroot: Failed to install build package list.
 
A1: при сборке пакетов — посредством <tt>--pkg-build-list=+branding-altlinux-starterkit-release</tt>
 
A2: при сборке образов с помощью [[mkimage]] — заданием <tt>IMAGE_INIT_LIST=+branding-simply-linux-release</tt> (не требуется при использовании [[m-p|mkimage-profiles]]).
 
A3: можно заставить {{pkg|apt}} [[Mkimage/Desktop/OldTroubles|указанием]] <tt>Dir::Etc::pkgpriorities</tt>, но это скорее ''ultima ratio''.
 
== как установить пакет из файла в hasher chroot? ==


Q: почему hasher перестал создавать хэши ({{path|base/*}}) для своего репозитория?
Q: как установить пакет из файла в hasher chroot?
$ hsh-install ./viber-4.2.2.6-2.rpm
E: Невозможно найти пакет ./viber-4.2.2.6-2.rpm


A: потому что для некоторого ускорения сборки они [http://lists.altlinux.org/pipermail/devel/2009-December/178354.html упразднены] в пользу непосредственного сканирования каталога (<tt>rpm-dir</tt> вместо <tt>rpm</tt> в {{path|sources.list}}).  Для создания хэшей при их публикации придётся запустить {{cmd|$hasher/aptbox/regenbasedir}} (или {{cmd|genbasedir --bloat}} совсем вручную).
A: hsh-install [https://lists.altlinux.org/pipermail/sisyphus/2015-May/363778.html не любит] относительных путей к пакетам, указывайте полный.
 
==Дополнительная деизоляция ради особых потребностей программ==
 
=== Я собираю пакет, но он ломается из-за того, что в сборочной среде нет <tt>/proc</tt> ===
 
A: [[Руководство по hasher#Монтирование /proc|Настройте монтирование /proc]].
 
=== как включить доступ в сеть из hasher chroot? ===
 
A: share_network=1 hsh-shell
 
=== как запретить доступ в сеть из hasher chroot? ===


== Q12 ==
A: например, сборка ведётся пользователем с логином username:
iptables -A OUTPUT -o venet0 -m owner --uid-owner username_a -j REJECT --reject-with icmp-net-unreachable
iptables -A OUTPUT -o venet0 -m owner --uid-owner username_b -j REJECT --reject-with icmp-net-unreachable


Q: есть ли споcоб запустить gui-шную программу внутри hasher?
=== есть ли споcоб запустить gui-шную программу внутри hasher? ===


A: да,
A: да,
hsh --initroot-only ~/hasher
  hsh-install xauth "гуишная прога"
  hsh-install xauth "гуишная прога"
  hsh-run -Y "гуишная прога"
  hsh-run -Y "гуишная прога"


<div id="virus"></div>
=== как запустить в хэшере браузер? ===
== Q13 ==
 
A: например, [http://lists.altlinux.org/pipermail/community/2015-July/684363.html так]:
hsh --initroot /path/to/hasher
hsh-install /path/to/hasher firefox fonts-otf-mozilla-fira xauth
share_ipc=yes share_network=yes hsh-run -Y --mountpoints=/proc,/dev/shm /path/to/hasher -- firefox --no-remote $@
 
В {{path|/etc/hasher-priv/system}} должно быть разрешено монтирование /proc и /dev/shm:
<tt>allowed_mountpoints=/proc,/dev/shm</tt>
 
В {{path|/etc/hasher-priv/fstab}} должна быть смонтирована /dev/shm:
<tt>tmpfs /dev/shm tmpfs defaults 0 0</tt>
 
=== Как запустить в хэшере qemu с поддержкой kvm? ===
Это может быть полезно для для ускорения работы <tt>qemu</tt> при использованиии [[Hasher/vm-run|<tt>rpm-build-vm</tt>]] (<tt>vm-run</tt> в <tt>%check</tt>).
 
'''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/kvm
 
== В рабочей системе некая библиотека находится, а в хэшере -- нет, хотя она лежит в одном и том же месте ==
 
Q[https://lists.altlinux.org/pipermail/devel/2018-April/204171.html]:<blockquote>
 
/usr/lib64/ghc-7.10.1/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M-ghc7.10.1.so: cannot open shared object file: No such file or directory


Q: правда, что Hasher — это вирус под Linux?
Получается, что в рабочей системе эта библиотека находится, а в хэшере --- нет. Притом она и там и там лежит в одном и том же месте:</blockquote>


A: действительно, существует [http://en.wikipedia.org/wiki/Linux_malware#Viruses ELF-вирус] [http://vxheavens.com/lib/vhe02.html Linux.Hasher], но в отличие от него — наличие технических механизмов заражения и саморазмножения в обсуждаемом hasher не показано.
$ ls /usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/lib*
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M.a
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M-ghc7.10.1.so
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M_p.a


== Q14 ==


Q: как включить доступ в сеть из hasher chroot?
A: Это может быть связано с тем, что не смонтирован {{path|/proc}}, а там в <code>RPATH</code>/<code>RUNPATH</code> в этих elf-ах используется <code>$ORIGIN</code> (см {{cmd|man ld-linux.so}}). Чтобы узнать место, где выполняемый elf лежал, {{prg|ld-linux}} как-то там смотрит
в {{path|/proc/}}, иначе работает так, как будто бы в текущей директории надо искать (и далее по стандартным путям).


A: share_network=1 hsh-shell
Натыкались на такое с {{prg|ghc}} и, вероятно, то же самое происходит с {{prg|java}} (в т.ч {{prg|closure}}), из-за этого при сборке [[Hasher/Руководство#cite_note-4|приходится]] обязательно [[Hasher/Руководство#Монтирование /proc|{{path|/proc}} монтировать]].


== Q15 ==
== hsh не запускается: execve: /.host/entry: Exec format error ==


Q: [http://lists.altlinux.org/pipermail/sisyphus/2008-June/331276.html Yury Aliaev]: "чтобы не скачивать одно и то же по многу раз для сборки разных пакетов, необходимо, чтобы скачанные пакеты где-то хранились и при следующем запуске брались уже из этого места. Опять-таки, если пакет в Сизифе более свежий, чем локально скачанный, то скачанный пакет должен обновиться на более свежий."
Q. При запуске <tt>hsh</tt> выдаёт ошибку:
hasher-priv: slave: chrootuid: execve: /.host/entry: Exec format error
hsh-initroot: Failed to create RPM database.


A: Можно добавить от себя в конфигурацию apt-а для hasher особое место для кэша apt, которое не будет чиститься hsh; например, общесистемный /var/cache/apt/archives/ -- см. [[Hasher/Tips#Кэширование скачиваемых apt-ом пакетов]].
A. Убрать все из ~/.hasher, и перенастроить его при необходимости.


== Q16 ==
== /etc/resolv.conf в чруте оказывается пустым даже при share_network=1 ==


Q: При запуске hsh с настройками apt по умолчанию (основанными на общесистемных /etc/apt/) процесс виснет на этапе какой-то установки пакетов через apt (при применении опции -v -- на сообщении "... пакеты будут установлены:" и список пакетов дальше).
Q. {{cmd|1 = share_network=1 hsh-shell}} оставляет {{path|/etc/resolv.conf}} пустым.


A: Может быть, в /etc/apt/sources.list, /etc/apt/sources.list.d/* есть источник-cdrom. (Например, у меня cdrom был прописан в /etc/apt/sources.list.d/sources.list -- я удалил этот файл, и больше hsh не зависает на этом этапе. Примечание: я запускаю вообще-то {{cmd|gear-hsh -v -- -v}}, а не чистый hsh.)
A. <tt>share_network</tt> -- это опция {{pkg|hasher-priv}}.<br/>
{{cmd|hasher-priv}} не занимается редактированием resolv.conf.<br/>
В {{pkg|hasher}} с версии <tt>1.4.1-alt1</tt> можно установить переменную {{cmd|1 = install_resolver_configuration_files=1}}, которая регулирует то, будет ли {{cmd|hsh-initroot}} копировать эти конфигурационные файлы (<tt>/etc/host.conf, /etc/hosts, /etc/resolv.conf</tt>). Её нужно или добавить в {{path|~/.hasher/config}}, или передать через окружение при запуске {{cmd|hsh --ini --no-cache}}. Обратите внимание, что так же необходимо указывать <tt>--no-cache</tt>. Пример:


Ответ найден благодаря сообщениям
$ install_resolver_configuration_files=1 hsh --initroot --no-cache
* [http://lists.altlinux.org/pipermail/devel/2007-June/140523.html "Оказалось, что в /etc/apt/sources.list.d/sources.list был прописан cdrom, и hasher просил его вставить"],
  $ share_network=1 hsh-shell
* [http://lists.altlinux.org/pipermail/devel/2008-August/158438.html "&lt;apt&gt; спрашивает что же ему выбрать, а хешер ему не отвечает. --Вообще он этого делать не должен. Покажите вывод hsh -v в районе затыка. --Причина оказалась в том, что &lt;...&gt; apt пытался взять его с CDROM."]


{{Category navigation|title=hasher|category=hasher|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=hasher|category=hasher|sortkey={{SUBPAGENAME}}}}
[[Категория:hasher]]
{{Category navigation|title=FAQ|category=FAQ|sortkey={{SUBPAGENAME}}}}
[[Категория:FAQ]]

Версия от 15:29, 12 апреля 2021

При запуске hsh я получаю ошибку: hsh-mkchroot: cannot access getugid1 helper

A: Добавьте себя в hasher.

Я добавил себя в hasher, но всё равно получаю ошибку hsh: /usr/libexec/hasher-priv/getconf.sh: cannot access getconf helper

A: Перелогиньтесь — hasher-useradd добавляет пользователя в новые группы.

В моём hasher собираются пакеты со странной архитектурой, которые не ставятся

A: Явно укажите архитектуру сборки.

В конце сборки в hasher выдаются ошибки вида some-packet.src.rpm: wrong PACKAGER

Q: В конце сборки в hasher выдаются ошибки вида

some-packet.src.rpm: wrong PACKAGER: Automated package hasher <hasher@localhost>

A1: Эти ошибки выдаются утилитой sisyphus_check, проверяющей соответствие пакетов правилам репозитория Sisyphus. Исправьте ошибки в spec-файле (обычно добавлением корректного тега Packager).

В частности, отсутствие тега Packager в spec-файле обычно (если не сделаны настройки, описанные в ответах ниже) приводит к такому результату (потому что в собранном пакете в качестве Packager будет некое значение по умолчанию).

Однако, если такой пакет без тега Packager будет собираться в girar (например, том, который работает на git.alt), то эта проверка будет успешно пройдена, потому что[1]: "girar builder, собирая пакет из подписанного git-тэга, указывает в качестве packager'а по умолчанию имя подписавшего git-тэг, поэтому, если поле Packager в спек-файле отсутствует, packager'ом собранного пакета окажется тот, кто подписал git-тэг." По правилам ALT это повлечёт назначение ответственным за пакет (maintainer'ом) нового packager'а (где это записано? так ли это?). Возможно, это не то, чего Вы хотели бы.

A2: Если пакет не предназначен для Sisyphus и выдаваемые ошибки связаны не с техническими проблемами в пакете, а с невыполнением политик репозитория (например, ограничение на тэг Packager и на PGP-подпись; возможно, будет интересна altbug #15376) — отключите часть проверок sisyphus_check; можно добавить в ~/.hasher/config:

no_sisyphus_check="packager,buildhost,gpg"

A3: В конфигурационный файл .hasher/config можно добавить поле packager (если есть альтовский логин):

packager="Your Name <login@altlinux.org>"

A4: У утилиты hsh есть ключик --packager, можно воспользоваться им:

$ gear -v --hasher -- hsh --target=i586 --packager="Andrew Clark <andyc@altlinux.org>" ~/hasher

A5: Если пакет собирать в локальном hasher-е и поле Packager содержит email не из домена altlinux, то возникнет схожая ошибка в модуле проверки changelog-а sisyphus_check. Так же как и с проверкой packager, можно добавить в no_sisyphus_check=changelog.

При запуске hsh я получаю ошибку hasher-priv: /path/to/workdir/chroot: prefix mismatch

Q: При запуске hsh я получаю ошибку

hasher-priv: /path/to/workdir/chroot: prefix mismatch, working directory
should start with one of directories listed in colon-separated prefix
list (~:/tmp/.private)
hsh-mkchroot: failed to make devices.

A: По умолчанию hasher позволяет располагать свою рабочую директорию в $HOME пользователя или в /tmp/.private. Или измените место, где создаётся рабочая директория, или разрешите дополнительные директории с помощью ключа prefix в /etc/hasher-priv/system (общесистемно) или /etc/hasher-priv/user.d/<USER> (для одного пользователя).

hsh не запускается, /.host/entry: No such file or directory

Q: При запуске hsh выдаёт ошибку:

hasher-priv: slave: chrootuid: execve: /.host/entry: No such file or directory
hsh-initroot: Failed to create RPM database.

A: Выключите все сменные носители в /etc/apt/sources.list, запустите apt-get update и еще раз повторите запуск hsh.

mkimage останавливается и чего-то ждёт

Q: Сборка дистрибутива останавливается на таких вот строчках:

 mki-cache: has started executing.
 mkimage: Processing 'copy-packages' ...
 mki-cache: has started executing.
 mki-expand-pkgs: has started executing. method=simple
 mki-copy-pkgs: has started executing.
 mkdir: created directory `.../profiles/main/.work/mki-copy-pkgs.verbose'

A: Выключите все сменные носители в /etc/apt/sources.listsources.list.d/*.list), запустите apt-get update и еще раз повторите запуск hsh.

При запуске hsh выдаёт ошибку: hasher-priv: openpty: No such file or directory

A: Проверьте, что у вас смонтирован /dev/pts на хост-системе.

hsh не запускается: /dev/null: Permission denied

Q: При запуске hsh выдаёт ошибку:

fakeroot daemon: /dev/null: Permission denied
fakeroot: error while starting the `faked' daemon.
hsh-initroot: Failed to create RPM database.

A: Проверьте, что файловая система, на которой располагается сборочный каталог, смонтирована без использования опции nodev, например:

$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=3145728k)

почему hasher перестал создавать хэши (base/*) для своего репозитория?

A: потому что для некоторого ускорения сборки они упразднены в пользу непосредственного сканирования каталога (rpm-dir вместо rpm в sources.list). Для создания хэшей при их публикации придётся запустить $hasher/aptbox/regenbasedir (или genbasedir --bloat совсем вручную).

правда, что Hasher — это вирус под Linux?

A: действительно, существует ELF-вирус Linux.Hasher, но в отличие от него — наличие технических механизмов заражения и саморазмножения в обсуждаемом hasher не показано.

Как кешировать и не скачивать одно и то же по многу раз для сборки разных пакетов?

Q: Yury Aliaev: "чтобы не скачивать одно и то же по многу раз для сборки разных пакетов, необходимо, чтобы скачанные пакеты где-то хранились и при следующем запуске брались уже из этого места. Опять-таки, если пакет в Сизифе более свежий, чем локально скачанный, то скачанный пакет должен обновиться на более свежий."

A: Можно добавить от себя в конфигурацию apt-а для hasher особое место для кэша apt, которое не будет чиститься hsh; например, общесистемный /var/cache/apt/archives/ -- см. Hasher/Tips#Кэширование скачиваемых apt-ом пакетов.

процесс виснет на этапе какой-то установки пакетов через apt

Q: При запуске hsh с настройками apt по умолчанию (основанными на общесистемных /etc/apt/) процесс виснет на этапе какой-то установки пакетов через apt (при применении опции -v -- на сообщении "... пакеты будут установлены:" и список пакетов дальше).

A: Может быть, в /etc/apt/sources.list, /etc/apt/sources.list.d/* есть источник-cdrom. (Например, у меня cdrom был прописан в /etc/apt/sources.list.d/sources.list -- я удалил этот файл, и больше hsh не зависает на этом этапе. Примечание: я запускаю вообще-то gear-hsh -v -- -v, а не чистый hsh.)

Ответ найден благодаря сообщениям

как передать параметры сборки rpm, например, --enable или --without?

A: --build-args для hsh или gear-hsh; при пересборке src.rpm также следует добавить --repackage-source:

hsh --build-args "--enable static" --repackage-source нужный.src.rpm
gear-hsh --build-args "--enable static"

«Пакет setup присутствует в базе данных, но не имеет доступной версии. […]»

Q: отчего при работающем sources.list хэшер может жаловаться: «Пакет setup присутствует в базе данных, но не имеет доступной версии. […] E: Для пакета setup не найдено подходящего кандидата для установки»?

A: проверьте, нет ли забытого указания архитектуры по умолчанию в ~/.hasher/config или ~/.rpmrc.

как обеспечить попадание в hasher chroot именно нужного варианта branding-*-release?

Q: как обеспечить попадание в hasher chroot именно нужного варианта branding-*-release? Получаю либо branding-sisyphus-server-light-release, либо конфликт запрошенного с ним:

error: failed dependencies:
       branding-sisyphus-server-light-release conflicts
with branding-altlinux-centaurus-release-7.0.5-alt1
hsh-initroot: Failed to install build package list.

A1: при сборке пакетов — посредством --pkg-build-list=+branding-altlinux-starterkit-release

A2: при сборке образов с помощью mkimage — заданием IMAGE_INIT_LIST=+branding-simply-linux-release (не требуется при использовании mkimage-profiles).

A3: можно заставить apt указанием Dir::Etc::pkgpriorities, но это скорее ultima ratio.

как установить пакет из файла в hasher chroot?

Q: как установить пакет из файла в hasher chroot?

$ hsh-install ./viber-4.2.2.6-2.rpm
E: Невозможно найти пакет ./viber-4.2.2.6-2.rpm

A: hsh-install не любит относительных путей к пакетам, указывайте полный.

Дополнительная деизоляция ради особых потребностей программ

Я собираю пакет, но он ломается из-за того, что в сборочной среде нет /proc

A: Настройте монтирование /proc.

как включить доступ в сеть из hasher chroot?

A: share_network=1 hsh-shell

как запретить доступ в сеть из hasher chroot?

A: например, сборка ведётся пользователем с логином username:

iptables -A OUTPUT -o venet0 -m owner --uid-owner username_a -j REJECT --reject-with icmp-net-unreachable
iptables -A OUTPUT -o venet0 -m owner --uid-owner username_b -j REJECT --reject-with icmp-net-unreachable

есть ли споcоб запустить gui-шную программу внутри hasher?

A: да,

hsh --initroot-only ~/hasher
hsh-install xauth "гуишная прога"
hsh-run -Y "гуишная прога"

как запустить в хэшере браузер?

A: например, так:

hsh --initroot /path/to/hasher
hsh-install /path/to/hasher firefox fonts-otf-mozilla-fira xauth
share_ipc=yes share_network=yes hsh-run -Y --mountpoints=/proc,/dev/shm /path/to/hasher -- firefox --no-remote $@

В /etc/hasher-priv/system должно быть разрешено монтирование /proc и /dev/shm:

allowed_mountpoints=/proc,/dev/shm

В /etc/hasher-priv/fstab должна быть смонтирована /dev/shm:

tmpfs /dev/shm tmpfs defaults 0 0

Как запустить в хэшере qemu с поддержкой kvm?

Это может быть полезно для для ускорения работы qemu при использованиии rpm-build-vm (vm-run в %check).

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/kvm

В рабочей системе некая библиотека находится, а в хэшере -- нет, хотя она лежит в одном и том же месте

Q[2]:

/usr/lib64/ghc-7.10.1/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M-ghc7.10.1.so: cannot open shared object file: No such file or directory

Получается, что в рабочей системе эта библиотека находится, а в хэшере --- нет. Притом она и там и там лежит в одном и том же месте:

$ ls /usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/lib*
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M.a
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M-ghc7.10.1.so
/usr/lib64/ghc-7.10.1/haske_IlDhIe25uAn0WJY379Nu1M/libHShaskeline-0.7.2.1-IlDhIe25uAn0WJY379Nu1M_p.a


A: Это может быть связано с тем, что не смонтирован /proc, а там в RPATH/RUNPATH в этих elf-ах используется $ORIGIN (см man ld-linux.so). Чтобы узнать место, где выполняемый elf лежал, ld-linux как-то там смотрит в /proc/, иначе работает так, как будто бы в текущей директории надо искать (и далее по стандартным путям).

Натыкались на такое с ghc и, вероятно, то же самое происходит с java (в т.ч closure), из-за этого при сборке приходится обязательно /proc монтировать.

hsh не запускается: execve: /.host/entry: Exec format error

Q. При запуске hsh выдаёт ошибку:

hasher-priv: slave: chrootuid: execve: /.host/entry: Exec format error
hsh-initroot: Failed to create RPM database.

A. Убрать все из ~/.hasher, и перенастроить его при необходимости.

/etc/resolv.conf в чруте оказывается пустым даже при share_network=1

Q. share_network=1 hsh-shell оставляет /etc/resolv.conf пустым.

A. share_network -- это опция hasher-priv.
hasher-priv не занимается редактированием resolv.conf.
В hasher с версии 1.4.1-alt1 можно установить переменную install_resolver_configuration_files=1, которая регулирует то, будет ли hsh-initroot копировать эти конфигурационные файлы (/etc/host.conf, /etc/hosts, /etc/resolv.conf). Её нужно или добавить в ~/.hasher/config, или передать через окружение при запуске hsh --ini --no-cache. Обратите внимание, что так же необходимо указывать --no-cache. Пример:

$ install_resolver_configuration_files=1 hsh --initroot --no-cache
$ share_network=1 hsh-shell