Получается, это чей-то артефакт. Чей? Перед тем, как нырять в инсталлятор, глянем ещё в одну важную инфраструктуру Debian — ответы на вопросы. Каждый раз, когда пакет задаёт вопрос, и во многих случаях, когда он вопроса не задаёт, но использует вариант по-умолчанию, и вопрос, и ответ фиксируются в специальной базе в Debian, которая называется debconf.
— Мы можем посмотреть на базу ответов (и даже выставить их до установки самого пакета — debconf-set-selections), для этого нам потребуется утилита debconf-get-selections из состава debconf-utils. К сожалению, ничего интересного не нашлось: (debconf-get-selections |grep -i resume вернул пусто).
debian-installer
У установщика есть своя база ответов на вопросы: /var/log/installer/cdebconf/questions.dat. К сожалению, там тоже нет ни слова про наш resume.
Зато рядом есть логи, в т.ч. syslog, куда пишется весь лог инсталляции. Там упоминается пакет base-installer, и на его странице мы можем видеть ссылку на сырцы.
🖥 Внутри них мы с лёгкостью находим ответ на наш вопрос:
resume="$(mapdevfs "$resume_devfs")"; then
...
if [ "$do_initrd" = yes ]; then
...
resumeconf=$IT_CONFDIR/resume
....
echo "RESUME=$resume" >> $resumeconf
mapdevfs — это утилита с понятным назначением, а интересная нам функция это get_resume_partition, которая читает /proc/swaps и выбирает там самую большую. Swap же у нас приходит от partman'а.
Ответ на наше тестовое задание: файл создаётся инсталлятором в /target'е в момент установки, т.е. мы говорим про well-known, но артефакт. В существующих в системе пакетах нет никого и ничего, чтобы меняло этот файл.
❗️ Подводя итог: dpkg и debconf — основные методы для поиска поставщиков файлов; поиск в /var/lib/dpkg/info позволяет увидеть операции над файлами на этапе установки; установщик может создавать файлы-артефакты, которые потом никем никогда не меняются (кроме пользователя), и это можно увидеть в коде установщика.
#Linux #DevOps #debconf | 🏃♂️ @iscode