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

Материал из ALT Linux Wiki
(→‎Обновите mkimage: по мотивам antique@)
м (→‎conflicts: не, не на***лося)
 
(не показаны 22 промежуточные версии 2 участников)
Строка 1: Строка 1:
== Обновите mkimage ==
= Обновите mkimage =
При каких-либо проблемах сборки образов обычно стоит обновить {{pkg|mkimage}} до последней версии из Sisyphus, загрузив и установив [http://packages.altlinux.org/ru/Sisyphus/srpms/mkimage/get одиночный пакет] (как правило, он прекрасно работает и на бранчах).  Известные исправления ошибок, приводящих к характерным взрывам:
При каких-либо проблемах сборки образов обычно стоит обновить {{pkg|mkimage}} до последней версии из Sisyphus, загрузив и установив [http://packages.altlinux.org/ru/Sisyphus/srpms/mkimage/get одиночный пакет] (как правило, он прекрасно работает и на бранчах).  Известные исправления ошибок, приводящих к характерным взрывам:


Строка 15: Строка 15:
  make[1]: *** [install2] Ошибка 2
  make[1]: *** [install2] Ошибка 2


== Отладка сборки профилей mkimage ==
= ln: failed to create hard link =
 
При наблюдении [https://lists.altlinux.org/pipermail/sisyphus/2013-October/361585.html подобных проблем] отключите ограничение на жёсткие ссылки на "чужие" файлы:
 
# apt-get install mkimage-preinstall
 
...и если используется несколько пар hasher numbers, следует передать явно заданный GLOBAL_HSH_NUMBER=1 (или иной подходящий) с тем, чтобы он констистентно применялся для формирования всех чрутов в процессе сборки.  В [[m-p]] такую строчку можно записать в {{path|~/.mkimage/profiles.mk}}, в любом случае можно передать аргументом {{cmd|make}}.
 
= Отладка сборки профилей mkimage =
Общие рекомендации, не являющиеся специфическими для какого-либо профиля или семейства.  Вообще помогает понимание логики работы apt и знание про -o Debug::pkgProblemResolver=true.
Общие рекомендации, не являющиеся специфическими для какого-либо профиля или семейства.  Вообще помогает понимание логики работы apt и знание про -o Debug::pkgProblemResolver=true.


=== filesystem и архитектуры ===
== filesystem и архитектуры ==
<tt>E: Package filesystem has no installation candidate</tt> обычно встречается при попытке собрать i586-дистрибутив на x86_64-узле, если «разъехались» по архитектурам --with-aptconf и --with-arch (например, сборка пытается пройти для x86_64, а apt нацелен на i586).
<tt>E: Package filesystem has no installation candidate</tt> обычно встречается при попытке собрать i586-дистрибутив на x86_64-узле, если «разъехались» по архитектурам apt.conf и собственно сборка (например, сборка пытается пройти для x86_64, а apt нацелен на i586).
 
Кажется, аналогично с <tt>E: Package setup has no installation candidate</tt>


=== Конфликты и битые зависимости ===
== Конфликты и битые зависимости ==
Два существенно разных случая: unmets (битые зависимости) и conflicts (конфликтующие пакеты, по отдельности сами по себе устанавливающиеся, но оказавшиеся вместе).
Два существенно разных случая: unmets (битые зависимости) и conflicts (конфликтующие пакеты, по отдельности сами по себе устанавливающиеся, но оказавшиеся вместе).
В общем случае может иметь смысл добавить в используемый {{path|apt.conf}} следующее:
Debug::pkgMarkInstall "true";
Debug::pkgProblemResolver "true";
Особенно если в задействованных списках пакетов применяется конструкция <tt>пакет-</tt>, бишь (зло)употребление возможностью apt по "размаркировке" пакетов для установки.


=== unmets ===
=== unmets ===
Строка 30: Строка 47:
E: Broken packages</pre>
E: Broken packages</pre>


То может иметь смысл проверить вручную так:
то может иметь смысл проверить вручную так:
<pre>hasher32:~/mkimage/build-LTSP/profiles/install2> hsh-install .work installer-stage2
<pre>hasher32:~/mkimage/build-LTSP/profiles/install2> hsh-install .work installer-stage2
Reading Package Lists...
Reading Package Lists...
Строка 40: Строка 57:
hsh-install: Failed to generate package file list.
hsh-install: Failed to generate package file list.
hasher32:~/mkimage/build-LTSP/profiles/install2></pre>
hasher32:~/mkimage/build-LTSP/profiles/install2></pre>
Если по одному вдруг становятся — следует попытаться поставить именно все и списком, так как вероятен конфликт между чем-то из ''всего'' требуемого этими пакетами.
Частным случаем заведомого анмета является пакет с пустым именем либо же отсутствующий файл со списком пакетов; [https://lists.altlinux.org/pipermail/devel-distro/2010-June/000597.html характерная ошибка]:
<pre>
E: Couldn't find package
</pre>


=== conflicts ===
=== conflicts ===
Строка 60: Строка 84:


* а вот при попытке поставить весь раскрытый из <tt>$(IMAGE_PACKAGES)</tt> список пакетов и воспроизводился облом:
* а вот при попытке поставить весь раскрытый из <tt>$(IMAGE_PACKAGES)</tt> список пакетов и воспроизводился облом:
   $ cd profiles/main/.work
   $ cd build/main/.work
   $ hsh-install -v . $(cat mki-copy-pkgs.verbose/req)
   $ hsh-install -v . $(cat mki-copy-pkgs.verbose/req)


* наконец было осознано, что в файлик req попадают _и_ ltsp-client, _и_ ltsp-server, а потом замечено и вспомнено, что они же конфликтуют!
* наконец осознал, что в файлик req попадают _и_ ltsp-client, _и_ ltsp-server, а потом заметил и вспомнил, что они же конфликтуют!
 
{{note|Если конфликт ожидаемый (например, надо уложить в RPMS.main несколько MTA или samba вместе с samba-DC), попробуйте изменить точку вхождения одного или обоих конфликтующих мест в общий список пакетов: в mkimage реализована эвристика, которая при конфликтах пытается разбивать список на части, что может в некоторых случаях не удаваться (см. тж. #30806).}}


* вот как можно яснее понять, в чём проблема — «protected» тут явным образом запрошенный ранее пакет:
* вот как можно яснее понять, в чём проблема — «protected» тут явным образом запрошенный ранее пакет:
Строка 74: Строка 100:
       Reinst Failed because of protected ltsp-client
       Reinst Failed because of protected ltsp-client


=== Live-images ===
{{note|Если перечисленные в изначальном сообщении об ошибке пакеты одной транзакцией устанавливаются (и указанные как запрошенные в профиле, и указанные как затребованные ими) -- после этого следует попытаться ещё раз установить весь развёрнутый список, наверняка вылезет conflicts или obsoletes, но уже в явном виде.}}
 
NB: если проблема не с инструментальным чрутом вроде <tt>main</tt>, а с рабочим вроде <tt>live</tt> (на примере из [[m-p]]) — соответственно добавляется два уровня каталогов и искать стоит {{path|mki-expand-pkgs.verbose}}:
 
  $ cd build/live/.work/chroot/.work
  $ ...
 
=== транзакции ===
Обратите внимание: <tt>*_PACKAGES</tt> и <tt>*_PACKAGES_REGEXP</tt> раскрываются и устанавливаются раздельно, что может привести к неожиданным эффектам, когда (например) какой-либо виртуальный пакет затребован одним из пакетов в <tt>IMAGE_PACKAGES</tt>, а в <tt>IMAGE_PACKAGES_REGEXP</tt> уточняется конкретная реализация; может оказаться так, что попадут оба провайдера, если они не конфликтуют между собой: первый вытягивается как дефолтный при раскрытии зависимостей первого списка, а второй приходит по второму списку. Решение — положить нужное в одну транзакцию (обычные имена пакетов вполне подходят как регэкспы).
 
См. тж. {{altbug|30805}} и {{altbug|30806}}.
 
=== пакеты-призраки ===
 
Порой в образ может попасть пакет, который вроде бы никто не тянет (его удаление не приводит к удалению любого другого пакета) и при этом который в явном виде не указан в профиле; наткнувшись на такое, стоит проверить, не предоставляет ли этот пакет чего-либо нужного другому (мета)пакету, что предоставляется также и другим пакетом, который уже затребован явно, но вследствие рассмотренной выше проблемы транзакций не удовлетворил вот ту зависимость на виртуальный пакет и она потянула ещё что-то (что мы и хотим найти и искоренить, да).
 
В данном случае требуемый для xsane в составе [[regular]]-mate.iso виртуальный webclient предоставлялся rekonq (который вытягивался "первым делом") и firefox (который был явно указан, но не попал в расчёт первой транзакции, видимо).
 
=== чистая конфигурация apt ===
 
Если творится что-то невообразимое (особенно при сборке с подключением [[biarch|x86_64-i586]]) -- например, не устанавливаются какие-либо вполне обычные пакеты, при этом пошаговое добавление того, на что жалуется apt, приводит к внезапной успешной сборке образа (особенно после добавления очередного имени пакета=версии согласно требованию) -- проверьте, что используете согласованную конфигурацию apt для _всех_ заданных репозиториев (а лучше единственного базового), а при необходимости именно нескольких репозиториев -- что в {{path|/etc/apt/preferences}} не кроется забытый сюрприз.
 
Поймал при подключенных x86_64-i586 ''и'' своём hasher repo, где как раз незадолго до того экспериментировал с libtiff:
<pre>
$ apt-cache -c=$HOME/apt/apt.conf.sisyphus.x86_64 policy libtiff5 
libtiff5:
  Установлен: 4.0.3-alt1
  Кандидат: 4.0.3-alt1.1
  Таблица версий:
    4.0.3-alt1.1 0
        500 file: x86_64/hasher pkgdir
*** 4.0.3-alt1 0
        500 file: x86_64/classic pkglist
        100 RPM Database
</pre>
 
=== подземный стук ===
 
Может оказаться неочевидным то, что mkimage при конфликтах в <tt>copy-packages</tt> пытается разбивать список пополам для раздельного просчёта транзакций -- т.е. если конфликтующее в списке устанавливаемого указано рядом, стоит попробовать изменить порядок задания пакетов так, чтобы разнести такие пакеты подальше друг от друга.
 
В клинических случаях можно, например, вставить между ними список пакетов из сотни строчек <tt>sh</tt> (хак предложен {{man|boyarsh}}; стоит понимать, что это всё равно объезд).
 
= live images =
Все вышесказанное справедливо и для Live-образов с поправкой на изменения пути.
Все вышесказанное справедливо и для Live-образов с поправкой на изменения пути.
Например:
Например:
   cd profiles/live/.work
   cd profiles/live/.work
= Свободное место =
Одна из возможных причин остановки сборки на
<pre>unable to make initial chroot</pre>
— закончившееся свободное место во временном каталоге, где собирается образ. Убедитесь (<code>df -h</code>), что там есть достаточно места.
Обратите внимание, если <code>control [[pam_mktemp]]</code> возвращает '''enabled''',
переменная TMP переопределяется автоматически и писать  <code>TMP=...</code> перед <code>make ...</code> не имеет смысла (TMP будет присвоено: /tmp/.private/$USER).


[[Категория:Mkimage]]
[[Категория:Mkimage]]

Текущая версия от 17:50, 1 июля 2024

Обновите mkimage

При каких-либо проблемах сборки образов обычно стоит обновить mkimage до последней версии из Sisyphus, загрузив и установив одиночный пакет (как правило, он прекрасно работает и на бранчах). Известные исправления ошибок, приводящих к характерным взрывам:

  • mkimage < 0.1.7-alt1 при включенном GLOBAL_VERBOSE:
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package mkdir:
hsh-install: failed to calculate package file list.
hsh-install: Failed to generate package file list.
make[2]: *** [prepare-workdir] Error 1
/bin/sh: command substitution: line 7: syntax error near unexpected token `('
/bin/sh: command substitution: line 7: `/usr/share/mkimage/tools/mki-expand-pkgs regexp ^kernel-(image|modules-())-()$'
make[2]: *** [build-image] Error 1                                                                                     
make[1]: *** [install2] Ошибка 2

ln: failed to create hard link

При наблюдении подобных проблем отключите ограничение на жёсткие ссылки на "чужие" файлы:

# apt-get install mkimage-preinstall

...и если используется несколько пар hasher numbers, следует передать явно заданный GLOBAL_HSH_NUMBER=1 (или иной подходящий) с тем, чтобы он констистентно применялся для формирования всех чрутов в процессе сборки. В m-p такую строчку можно записать в ~/.mkimage/profiles.mk, в любом случае можно передать аргументом make.

Отладка сборки профилей mkimage

Общие рекомендации, не являющиеся специфическими для какого-либо профиля или семейства. Вообще помогает понимание логики работы apt и знание про -o Debug::pkgProblemResolver=true.

filesystem и архитектуры

E: Package filesystem has no installation candidate обычно встречается при попытке собрать i586-дистрибутив на x86_64-узле, если «разъехались» по архитектурам apt.conf и собственно сборка (например, сборка пытается пройти для x86_64, а apt нацелен на i586).

Кажется, аналогично с E: Package setup has no installation candidate

Конфликты и битые зависимости

Два существенно разных случая: unmets (битые зависимости) и conflicts (конфликтующие пакеты, по отдельности сами по себе устанавливающиеся, но оказавшиеся вместе).

В общем случае может иметь смысл добавить в используемый apt.conf следующее:

Debug::pkgMarkInstall "true";
Debug::pkgProblemResolver "true";

Особенно если в задействованных списках пакетов применяется конструкция пакет-, бишь (зло)употребление возможностью apt по "размаркировке" пакетов для установки.

unmets

Если возникают проблемы вроде неустанавливающихся пакетов:

The following packages have unmet dependencies:
  installer-ltsp-stage2: Depends: installer-stage2 but it is not going to be installed
E: Broken packages

то может иметь смысл проверить вручную так:

hasher32:~/mkimage/build-LTSP/profiles/install2> hsh-install .work installer-stage2
Reading Package Lists...
[...]
The following packages have unmet dependencies:
  installer-stage2: Depends: installer (= 0.2-alt2) but it is not going to be installed
E: Broken packages
hsh-install: failed to calculate package file list.
hsh-install: Failed to generate package file list.
hasher32:~/mkimage/build-LTSP/profiles/install2>

Если по одному вдруг становятся — следует попытаться поставить именно все и списком, так как вероятен конфликт между чем-то из всего требуемого этими пакетами.

Частным случаем заведомого анмета является пакет с пустым именем либо же отсутствующий файл со списком пакетов; характерная ошибка:

E: Couldn't find package

conflicts

При включенном GLOBAL_VERBOSE=1 в процессе работы скрипта mki-copy-pkgs (цель copy-packages) образуется подкаталог .work/mki-copy-pkgs.verbose/, содержащий ценные данные — список пакетов для установки и stderr, полученный при его формировании apt’ом.

Поскольку индивидуально конфликтующие пакеты устанавливаются, то диагностика может быть нетривиальной и следует оперировать именно списком пакетов, чтобы понять, что это не анмет, а конфликт.

Огромная благодарность Алексею Гладкову (legion@altlinux) за доброе и терпеливое участие в разборе случая, получившегося при адаптации профиля Desktop 5.0a по мотивам Terminal 4.0 вследствие наличия в последнем заведомо конфликтующих пакетов ltsp-server и ltsp-client в компонентах base и disk, которые там уже были смержены в одну main.

Пример в итоге получился такой:

  • make давал останов с таким сообщением:
 The following packages have unmet dependencies:
   ltsp-client-full: Depends: ltsp-client (>= 5.1)
 E: Broken packages
  • в .work/mki-copy-pkgs.verbose/err содержались те же данные
  • hsh-install .work ltsp-client замечательно отрабатывал
  • а вот при попытке поставить весь раскрытый из $(IMAGE_PACKAGES) список пакетов и воспроизводился облом:
 $ cd build/main/.work
 $ hsh-install -v . $(cat mki-copy-pkgs.verbose/req)
  • наконец осознал, что в файлик req попадают _и_ ltsp-client, _и_ ltsp-server, а потом заметил и вспомнил, что они же конфликтуют!
Примечание: Если конфликт ожидаемый (например, надо уложить в RPMS.main несколько MTA или samba вместе с samba-DC), попробуйте изменить точку вхождения одного или обоих конфликтующих мест в общий список пакетов: в mkimage реализована эвристика, которая при конфликтах пытается разбивать список на части, что может в некоторых случаях не удаваться (см. тж. #30806).


  • вот как можно яснее понять, в чём проблема — «protected» тут явным образом запрошенный ранее пакет:
 $ cd profiles/main/.work
 $ aptbox/apt-get install -y -o Debug::pkgProblemResolver=1 $(cat mki-copy-pkgs.verbose/req)
 [...]
 Investigating alterator-ltsconf
 Package alterator-ltsconf has broken dep on ltsp-server
   Considering ltsp-server 2 as a solution to alterator-ltsconf 9999
     Reinst Failed because of protected ltsp-client
Примечание: Если перечисленные в изначальном сообщении об ошибке пакеты одной транзакцией устанавливаются (и указанные как запрошенные в профиле, и указанные как затребованные ими) -- после этого следует попытаться ещё раз установить весь развёрнутый список, наверняка вылезет conflicts или obsoletes, но уже в явном виде.


NB: если проблема не с инструментальным чрутом вроде main, а с рабочим вроде live (на примере из m-p) — соответственно добавляется два уровня каталогов и искать стоит mki-expand-pkgs.verbose:

 $ cd build/live/.work/chroot/.work
 $ ...

транзакции

Обратите внимание: *_PACKAGES и *_PACKAGES_REGEXP раскрываются и устанавливаются раздельно, что может привести к неожиданным эффектам, когда (например) какой-либо виртуальный пакет затребован одним из пакетов в IMAGE_PACKAGES, а в IMAGE_PACKAGES_REGEXP уточняется конкретная реализация; может оказаться так, что попадут оба провайдера, если они не конфликтуют между собой: первый вытягивается как дефолтный при раскрытии зависимостей первого списка, а второй приходит по второму списку. Решение — положить нужное в одну транзакцию (обычные имена пакетов вполне подходят как регэкспы).

См. тж. altbug #30805 и altbug #30806.

пакеты-призраки

Порой в образ может попасть пакет, который вроде бы никто не тянет (его удаление не приводит к удалению любого другого пакета) и при этом который в явном виде не указан в профиле; наткнувшись на такое, стоит проверить, не предоставляет ли этот пакет чего-либо нужного другому (мета)пакету, что предоставляется также и другим пакетом, который уже затребован явно, но вследствие рассмотренной выше проблемы транзакций не удовлетворил вот ту зависимость на виртуальный пакет и она потянула ещё что-то (что мы и хотим найти и искоренить, да).

В данном случае требуемый для xsane в составе regular-mate.iso виртуальный webclient предоставлялся rekonq (который вытягивался "первым делом") и firefox (который был явно указан, но не попал в расчёт первой транзакции, видимо).

чистая конфигурация apt

Если творится что-то невообразимое (особенно при сборке с подключением x86_64-i586) -- например, не устанавливаются какие-либо вполне обычные пакеты, при этом пошаговое добавление того, на что жалуется apt, приводит к внезапной успешной сборке образа (особенно после добавления очередного имени пакета=версии согласно требованию) -- проверьте, что используете согласованную конфигурацию apt для _всех_ заданных репозиториев (а лучше единственного базового), а при необходимости именно нескольких репозиториев -- что в /etc/apt/preferences не кроется забытый сюрприз.

Поймал при подключенных x86_64-i586 и своём hasher repo, где как раз незадолго до того экспериментировал с libtiff:

$ apt-cache -c=$HOME/apt/apt.conf.sisyphus.x86_64 policy libtiff5   
libtiff5:
  Установлен: 4.0.3-alt1
  Кандидат: 4.0.3-alt1.1
  Таблица версий:
     4.0.3-alt1.1 0
        500 file: x86_64/hasher pkgdir
 *** 4.0.3-alt1 0
        500 file: x86_64/classic pkglist
        100 RPM Database

подземный стук

Может оказаться неочевидным то, что mkimage при конфликтах в copy-packages пытается разбивать список пополам для раздельного просчёта транзакций -- т.е. если конфликтующее в списке устанавливаемого указано рядом, стоит попробовать изменить порядок задания пакетов так, чтобы разнести такие пакеты подальше друг от друга.

В клинических случаях можно, например, вставить между ними список пакетов из сотни строчек sh (хак предложен boyarsh@; стоит понимать, что это всё равно объезд).

live images

Все вышесказанное справедливо и для Live-образов с поправкой на изменения пути. Например:

 cd profiles/live/.work

Свободное место

Одна из возможных причин остановки сборки на

unable to make initial chroot

— закончившееся свободное место во временном каталоге, где собирается образ. Убедитесь (df -h), что там есть достаточно места.

Обратите внимание, если control pam_mktemp возвращает enabled, переменная TMP переопределяется автоматически и писать TMP=... перед make ... не имеет смысла (TMP будет присвоено: /tmp/.private/$USER).