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

Материал из ALT Linux Wiki
м (→‎Q11: DRY)
м (выдал "Q*" более полезные заголовки)
(не показано 29 промежуточных версий 8 участников)
Строка 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>).


A2: Если пакет не предназначен для Sisyphus, а выдаваемые ошибки связаны не с техническими проблемами в пакете, а с невыполнением политик репозитория (например, ограничение на тэг <tt>Packager</tt> и на PGP-подпись) — [[Руководство по hasher#Отключение проверок sisyphus_check|отключите часть проверок <tt>sisyphus_check</tt>]].
В частности, отсутствие тега <tt>Packager</tt> в spec-файле обычно (если не сделаны настройки, описанные в ответах ниже) приводит к такому результату (потому что в собранном пакете в качестве <tt>Packager</tt> будет некое значение по умолчанию).


A3: В конфигурационный файл .hasher/config, можно добавить поле 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-подпись; возможно, будет интересна {{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"
 
A3: В конфигурационный файл .hasher/config можно добавить поле packager (если есть альтовский логин):
  packager="Your Name <login@altlinux.org>"
  packager="Your Name <login@altlinux.org>"


A4: У утилиты hsh, есть ключик --packager, можно воспользоваться им:
A4: У утилиты hsh есть ключик --packager, можно воспользоваться им:
  $ 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> я получаю ошибку
Строка 51: Строка 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> выдаёт ошибку:
Строка 60: Строка 52:
и еще раз повторите запуск <tt>hsh</tt>.
и еще раз повторите запуск <tt>hsh</tt>.


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


Q: Сборка дистрибутива останавливается на таких вот строчках:
Q: Сборка дистрибутива останавливается на таких вот строчках:
Строка 73: Строка 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> выдаёт ошибку:
Строка 87: Строка 76:
  hsh-initroot: Failed to create RPM database.
  hsh-initroot: Failed to create RPM database.


A: Проверьте, что файловая система, на которой располагается сборочный каталог, смонтирована ''без'' использования опции nodev, например:
A: Проверьте, что файловая система, на которой располагается сборочный каталог, смонтирована ''без'' использования опции <tt>nodev</tt>, например:
  $ mount | grep local
  $ mount | grep /tmp
  /dev/sda3 on /usr/local type ext3 (rw,relatime)
  tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=3145728k)
 
== почему 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-ом пакетов]].


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


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


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: Может быть, в /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 chroot?
$ hsh-install ./viber-4.2.2.6-2.rpm
E: Невозможно найти пакет ./viber-4.2.2.6-2.rpm
 
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 "гуишная прога"


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


Q: правда, что Hasher — это вирус под Linux?
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 $@


A: действительно, существует [http://en.wikipedia.org/wiki/Linux_malware#Viruses ELF-вирус] [http://vxheavens.com/lib/vhe02.html Linux.Hasher], но в отличие от него — наличие технических механизмов заражения и саморазмножения в обсуждаемом hasher не показано.
В {{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>
 
== В рабочей системе некая библиотека находится, а в хэшере -- нет, хотя она лежит в одном и том же месте ==
 
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
 
Получается, что в рабочей системе эта библиотека находится, а в хэшере --- нет. Притом она и там и там лежит в одном и том же месте:</blockquote>
 
$ 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: Это может быть связано с тем, что не смонтирован {{path|/proc}}, а там в <code>RPATH</code>/<code>RUNPATH</code> в этих elf-ах используется <code>$ORIGIN</code> (см {{cmd|man ld-linux.so}}). Чтобы узнать место, где выполняемый elf лежал, {{prg|ld-linux}} как-то там смотрит
в {{path|/proc/}}, иначе работает так, как будто бы в текущей директории надо искать (и далее по стандартным путям).
 
Натыкались на такое с {{prg|ghc}} и, вероятно, то же самое происходит с {{prg|java}} (в т.ч {{prg|closure}}), из-за этого при сборке [[Hasher/Руководство#cite_note-4|приходится]] обязательно [[Hasher/Руководство#Монтирование /proc|{{path|/proc}} монтировать]].
 
== hsh не запускается: execve: /.host/entry: Exec format error ==
 
Q. При запуске <tt>hsh</tt> выдаёт ошибку:
hasher-priv: slave: chrootuid: execve: /.host/entry: Exec format error
hsh-initroot: Failed to create RPM database.
 
A. Убрать все из ~/.hasher, и перенастроить его при необходимости.


{{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]]

Версия от 12:47, 19 июля 2019

При запуске 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

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

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, и перенастроить его при необходимости.