!
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, будеm
