Есть у меня плата Cubietruck на ARM-процессоре. На ней стоит дистрибутив Armbian на основе Debian. Там же запущено несколько nspawn-контейнеров с другими дистрибутива. Одни из них был Gentoo. Всё вместе работало довольно исправно, только пакеты в Gentoo всё же обновляются раньше, чем выходят версии Debian. И вот во время одного из обновлений контейнер сломался и больше запускаться не хотел.
(Свои приключения буду описывать по памяти.)
По логам было видно, что всё упало после обновления "sys-libs/glibc" до версии 2.32, которая оказалась совсем не совместима с ядром в хостовой системе. Контейнер у меня был в основном для работы ноды Zeronet и поддержания её в актуальном состоянии, позже я там пробовал держать ноду ipfs. Из-за того, что первое было на Python, а второе на Go, перенести их в другое место труда не составило.
О контейнере я забыл и вспомнил только после выхода Debian 11. В этой версии довольно сильно обновилось ядро. Можно было попробовать оживить контейнер, что я и сделал. Контейнер запустился, и даже получилось туда зайти по ssh. А вот с обновлением там было всё плохо, потому что система как раз и упала в процессе большого обновления, то есть часть пакетом обновилась, а часть осталось старых версий. При этом команда "emerge" выдавала сообщение "no python-exec wrapped executable found in /usr/lib/python-exec". При этом в каталоге "/usr/lib/python-exec/python3.6" нужные файлы нашлись. Запуск "emerge" из этого каталога вполне работал. Можно было пробовать обновить систему, но это у меня опять не получилось из-за конфликта пакетов. Нужно было обновить "dev-lang/perl", но это обновление почему-то блокировалось установленной версией. Не получалось даже обновить "sys-apps/portage" до актуальной версии.
Когда-то я читал в новостях что-то про необходимость запуска программы "perl-cleaner" при обновлении "dev-lang/perl", но все обновления проходили штатно без вспомогательных действий. Терять уже было нечего, да и у меня уже был чисто спортивный интерес поднять контейнер. Программа отработала, но в самом конце споткнулась из-за невозможности запустить "emerge", но при этом показал командную строку. Я подставил в начало полученной строки полный путь до программы, процесс обновления "dev-lang/perl" успешно запустился и дошёл до конца.
Теперь у меня в системе была актуальная версия пакет, можно было пробовать сразу запустить полное обновление системы, но почему-то полез обновлять только "dev-lang/python". После обновления команда "emerge" перестала запускаться даже по прямому пути. Похоже, что после установки новой версии интерпретатора старая была удалена. В очередной раз помучив Google, я на каком-то сайте нашёл рекомендацию просто скачать и распаковать архив с "sys-apps/portage" и запустить программу "emerge" из распакованного пакета.
Я нашёл нужный архив на зеркале Яндекс по адресу http://mirror.yandex.ru/gentoo-distfiles/distfiles/. Скачал файл в домашний каталог, там же распаковал и запустил. Программа заработала, ругнувшись на неизвестные ей куски "layman". При этом получилось обновить дерево основного репозитория и запустить обновление. Обновить предстояло 191 пакет. На хиленьком Cubietruck процесс занял больше двух суток. В процессе даже отваливался доступ по ssh, но процесс обновления был запущен внутри screen, а доступ к контейнеру можно было получить, подключившись такой командой:
machinectl login gentoocubie
При этом появлялся обычный запрос имени пользователя и пароля. При таком способе входа странно работал mc, но следить за процессом сборки было можно. Для закрытия сеанса после logout надо было нажать "Ctrl+]]]".
В итоге система успешно обновилась, ssh опять стал пускать в систему, пакет "sys-apps/portage" тоже был актуальной версии.
