!
Linux User Group НовосибирскОт теории к практике. Собственно, из-за чего есть пошёл весь сыр-бор.
Обновление системы в Linux можно делать по большей части без перезапуска и ухода в отдельный спецрежим. Для бинарных дистрибутивов это процесс даже достаточно быстрый. Если только не надо обновляться на следующий релиз…
Вобщем у всех систем главная проблема одна и та же — после серьёзного обновления система может оказаться поломанной и перестать запускаться полностью или частично. И в этом случае предусмотрительно сделанный снимок в состоянии спасти положение дел.
Но есть и другая особенность — хотя #
Linux и позволяет заменять в данный момент используемые файлы и до перезапуска/перепрочтения прежняя версия продолжит работать как ни в чём не бывало, иногда нужно за время обновления запустить новую или перезапустить запущенную программу. С предсказуемым результатом.
ПроблемаОбновление #
Gentoo, особенно когда обновляешься редко, занимает много времени.
В процессе таких обновлений может поменяться много чего, в частности библиотеки и фреймворки, от которых зависят другие пакеты.
Между обновлением библиотеки и нужной программы может пройти некоторое время, в пределах которого программа запускаться не сможет.
В итоге это приводит к тому, что работать одновременно с обновлением становится проблематично. Программы нельзя перезапускать, запуск новых невозможен. При обновлении Qt/Gtk основанные на них ДЕ начинают рассыпаться по кускам.
Решение первое — обновляемся авансомPortage умеет собирать и откладывать бинарные пакеты для последующей быстрой установки при помощи ключа в
emerge --buildpkg-only или собирать, ставить и откладывать при помощи
emerge --buildpkg.
Но в первом случае он не сможет собрать пакеты, который зависят от обновления других. Во втором, он их всё равно ставит.
По этому делаем следующий финт ушами:
0. Делаем ro снимок всех файловых систем, на всякий случай.
1. Делаем rw снимок всех файловых систем, кроме /home, поскольку оно обновлением не затрагивается.
2. Монтируем наши rw снимки куда-нибудь (если у вас отдельные /var, /opt, /usr и что-то ещё, монтируем внутрь), чтобы получился chroot.
3. Подмонтируем runtime директории /dev, /sys, /proc, /run в наш chroot при помощи
mount --rbind, чтобы всякие /sys/fs/cgroup, /dev/shm и так далее, тоже примонтировались.
4. Делаем chroot в полученную структуру.
5. Обновляем систему с
emerge --buildpkg, чтобы в PKGDIR были собраны все необходимые пакеты.
6. После успешного обновления переносим пакеты из PKGDIR снапшота в основную систему.
7. На основной системе обновляемся из этих пакетов при помощи
emerge --usepkg --with-bdeps=y. Параметр
--with-bdeps=y необходим в данном случае, поскольку иначе некоторые пакеты установлены не будут, так как нужны только для сборки, но без них
emerge --depclean будет ругаться на недостающие зависимости.
8. После этого можно разбирать chroot и удалять снимки. Чистые ro стоит оставить, на всякий случай.
9. Если что-то пошло не так, мы ничего глобально не сломали, откатываться не надо, достаточно разобрать и удалить эти rw снимки и можно начинать всё заново.
Таким образом можно обновить всю систему с зависимостями в фоне и затем накатить попокетно на боевую систему.
Пункты 6, 7 представляют собой ручную замену отсутствующей операции накатывания изменений снимка на источник, в частности
lvconvert --merge из LVM.
Если под PKGDIR у вас отдельный раздел/subvolume, который можно примонтировать одновременно в живой системе и в chroot, это сэкономит 6 пункт. Монтирование папки при помощи
mount --rbind тоже сработает, главное не запутаться, что куда идёт и не заколцевать что-нибудь.
Плюсы:
1. Нет проблем со сборкой пакетов зависящих друг от друга.
2. Можно продолжать работать, приложение не оказываются в полуобновлённом виде.
3. Если что-то пошло не так на этапе сборки, на живую систему оно не влияет и можно спокойно попытаться это решить.
4. В случае серьёзных проблем не надо перезагружаться, откатываться, жонглировать файловыми системами.
5. Не требует особого планирования в части разбивки файловых систем и как разделять на subvolumes, будет работать и в случае одного на весь диск, большого раздела #
BTRFS, нарезанного на subvolumes, так и для системы с отдельными разделами #
BTRFS без subvolumes.
Минусы:
1. Установка собранных пакетов на живую систему занимает дополнительное время.
2. Во время установки бинарных пакетов всё равно проблематично работать.
3. Не предполагается возможности проверить работоспособность обновлённой системы, поскольку полноценная проверка потребует загрузиться в обновлённую систему, чего хотелось избежать.
Вместо заключенияЭто не единственный способ, но самый прямолинейный и не требующий особой подготовки.
А так же с минимальной сложностью восстановления в случае кривого обновления — просто удалить и начать снова.
Способ опробован, система чувствует себя хорошо. Если в chroot удалось довести обновление до конца, установка пакетов на живую уже не должна сломаться. Хотя это и не защищает от ошибок в самих программах, которые могут проявить себя после перезапуска.
Как вариант этого способа, вместо установки пакетов на живую систему можно попробовать перенести изменения из снимков при помощи
rsync --archive --update, но его я не пробовал.
Теоретически он должен быть быстрее, переноситься будут только изменения сделанные в процессе обновления, в том числе база portage, и не будут затронуты те файлы, которые изменились на живой системе.
Я не расписываю конкретные команды для обновления таким способом, поскольку у всех могут быть разные исходные данные. Но если надо, я посвящу этому следующий пост чуть позже
