//kalinux.info
Новости 182 просмотров

Отслеживание и исправление ошибки

Отслеживание и исправление ошибки

Некоторое время ошибка с LVM мешала установке Kali Linux 1.0.4 это было сообщено в нашу систему отслеживания ошибок. Эта ошибка была высокоприоритетной в нашем TODO, поскольку зашифрованные установки являются важной особенностью в нашей отрасли, поэтому мы хотели вырезать эту ошибку как можно скорее. В этой статье описывается процесс отладки, идентификации и исправления этой ошибки в Kali Linux и, в конечном счете, в Debian.

Сама ошибка была странной; установка Kali Linux с опцией «LVM Encrypted» приведет к неудачной загрузке после завершения установки:

Обход, предложенный в отчете об ошибке, показал, что файл /etc/crypttab был пуст. Переустановив вручную зашифрованный раздел, перезаполнив его необходимыми параметрами, а затем обновив initramfs, машина снова загрузится в зашифрованный раздел.

Теперь, когда проблема определена, решение оказалось простым. Возможно, что-то было неправильно с тем, как файл /etc/crypttab обновляется во время процесса установки. Наш следующий шаг состоял в том, чтобы исследовать сценарии, которые отвечают за это обновление, и посмотреть, есть ли какие-либо ошибки в процессе обновления файла. Но как бы мы нашли точный сценарий, ответственный за это обновление, и как еслиб мы могли бы выяснить, в каком пакете он живет?

К нашему спасению приходит DebianInstaller. Используя этот набор скриптов, мы проверили все дерево исходных текстов DebianInstaller. Это позволит нам искать скрипты, которые влияют на /etc/crypttab с гораздо большей легкостью.

root@kalima:~# svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer
root@kalima:~# cd debian-installer
root@kalima:~/debian-installer# scripts/git-setup
root@kalima:~/debian-installer# mr -p checkout
root@kalima:~/debian-installer# grep -r '/etc/crypttab' * |grep -v ^manual
...
packages/partman-crypto/finish.d/crypto_config:# dm-crypt: creates /etc/crypttab entries
packages/partman-crypto/finish.d/crypto_config: echo "$target $source $keyfile $opts" >> /target/etc/crypttab
...
root@kalima:~/debian-installer#

Мы видим выше, что это скрипт crypto_config, который записывается в /etc/crypttab , который находится в пакете partman-crypto.

В идеале, мы хотели бы отладить этот скрипт и посмотреть, где проблема, но как мы это сделаем на живом установочном носителе? Ответ относительно прост - нам просто нужно было открыть командную строку во время процесса установки. Хитрость заключается в том, чтобы вызвать нашу оболочку отладки (нажав CTRL+ ALT+F2) на правильном этапе установки - в нашем случае нам нужно было прервать установку до того, как был запущен скрипт crypto_config, но после того, как был установлен partman-crypto, поэтому начало процесса будет хорошим местом. Мы приступили к редактированию /lib/partman/finish.d/55_crypto_config и добавили « set -x » в начале скрипта:

Затем мы позволяем установщику выполнить свою задачу и незадолго до завершения установки, мы заглянули в /var/log/syslog в другой оболочке. К нашему удивлению, мы увидели, что файл /etc/crypttab был обновлен, что противоречит нашим первоначальным убеждениям, что можно увидеть в syslog установки. WTH.

Aug 28 21:57:42 main-menu[954]: (process:9810): crypttab_add_entry
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/sda5
Aug 28 21:57:42 main-menu[954]: (process:9810): /var/lib/partman/devices/=dev=sda/256901120-160041009151
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/mapper/sda5_crypt
...
Aug 28 21:57:42 main-menu[954]: (process:9810): echo
Aug 28 21:57:42 main-menu[954]: (process:9810): sda5_crypt UUID=6250dbca-648b-4848-9132-cfa900ab5874 none luks

Здесь мы начали царапать головы. Если проблема не в написании этого файла (как мы и ожидали), то почему после установки был пустой файл /etc/crypttab? Возможно, проблема в том, что проблема не в partman-crypto, а в том, как live-build генерирует наши ISO? Мы протестировали эту нашу теорию, используя мини-инсталляцию Kali mini (не встроенную в live-build) и заметили, что зашифрованные установки LVM отлично работают при использовании этого установочного носителя.

Мы знаем, что live-installer использует tar для копирования всей файловой системы в установленный /target каталог и предполагает, что файловые системы пусты, что в основном верно, поскольку они были созданы только partman. Это означает, что любой предварительно существующий файл может быть перезаписан, если они также находятся в живом изображении, которое в этом случае происходило с /etc/crypttab.

Дальнейшее исследование показало, что проблема была в режиме реального времени, в результате чего он перезаписывает сгенерированный файл /etc/crypttab. У живого установщика уже есть некоторые положения, чтобы не перезаписывать /etc/fstab, так что это просто вопрос об обобщении этого правила и включая файл /etc/crypttab:

diff --git a/debian/live-installer.postinst b/debian/live-installer.postinst
index 9a39d8d..bc40b84 100644 (file)
--- a/debian/live-installer.postinst
+++ b/debian/live-installer.postinst
@@ -8,6 +8,8 @@ db_capb backup
# Architecture and OS detection
ARCH=`udpkg --print-architecture`
OS=`udpkg --print-os`
+# Files that must not be overwritten by copy of live system
+FILES_TO_PRESERVE="/etc/fstab /etc/crypttab"

NEWLINE="
"
@@ -34,11 +36,12 @@ install_live_system () {
# symlinks there.
rmdir /target/var/lock /target/var/run 2>/dev/null || true

- # Backup pre-existing /etc/fstab as it will be overwritten by the
- # copy of the live system
- if [ -e /target/etc/fstab ] && [ ! -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab /target/etc/fstab.live-installer
- fi
+ # Backup files that should not be overwritten by the copy
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target$f ] && [ ! -e /target/${f}.live-installer ]; then
+ mv /target$f /target${f}.live-installer
+ fi
+ done

for place in $PLACES; do
[ ! -e $place ] && continue
@@ -83,10 +86,12 @@ install_live_system () {
eval ${SUPPORT}_teardown
done

- # Restore the fstab file created by d-i
- if [ -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab.live-installer /target/etc/fstab
- fi
+ # Restore important configuration files
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target${f}.live-installer ]; then
+ mv /target${f}.live-installer /target$f
+ fi
+ done

if [ ${PLACE_FOUND} -eq 0 ]; then
error "Could not find any live images"

Вышеупомянутый патч исправил проблему для нас, позволив зашифрованным установкам LVM завершить и успешно загрузиться. Как и с любыми ошибками Debian, с которыми мы сталкиваемся, мы отправляем исправления обратно в Debian, чтобы улучшить дистрибутив, на котором мы строим. Исправление для этой ошибки установщика появится в следующей выпуске (1.0.5) на следующей неделе. Люди генерируют свои собственные образы ISO, хотя live-build автоматически получит фиксированный пакет.