Автор: Алексей Федорчук
2005.12.08
Около девяти месяцев прошло со дня выхода первого официального релиза DragonFlyBSD, когда начали поговаривать о релизе втором. И хотя в промежутках ОСестроительная мысль не стояла на месте — регулярно выходили ежедневные снапшоты системы, каждый третий или четвертый из которых получал, и заслуженно, статус стабильного, — выхода новой официальной версии с нетерпением ждали все пользователи этой операционки. Число которых, нужно сказать, росло в геометрической прогрессии. Так, только среди посетителей Юниксфорума за несколько месяцев оно возросло втрое (с одного до трех).
Сначала были неясности со статусом и номером грядущей версии. Оптимисты надеялись, что это будет тот самый релиз 2.0, который получит, наконец, собственную систему управления пакетами. Однако сообщение Мэтта Диллона от середины марта внесло ясность: новый релиз выйдет к ежегодной конференции USENIX, и имя ему будет — 1.5. Предполагалось, что новшеств в нем будет весьма много, в частности, умолчальный компилятор сменит свой номер gcc-2.9 на gcc-3.4. Но о системе пакетного менеджмента в списках рассылки хранилось молчание…
И вот — свершилось: 8 апреля было объявлено о релизе. Правда, номер его оказался 1.2. А список обновлений впечатлял изобилием внутренних усовершенствований, однако лишь считанные из них заметны невооруженному глазу обычного пользователя. И у последнего возникает резонный вопрос: а стоит ли обновляться?
Ответ на этот вопрос зависит от двух обстоятельство. Первое — для чего используется DragonFly, для экспериментов или практической работы? В первом случае ответ — однозначно положительный. Впрочем, пользователи-экспериментаторы и так регулярно обновляют систему через CVS, и вполне в курсе всех новшеств…
Если же DragonFly применяется для практической работы (как у вашего покорного слуги, где она является единственной операционкой на БМП — Боевой Машине Писателя), то встает проблема трудо- и времени-затрат на обновление. Которая и будет предметом дальнейшего рассмотрения.
Текущая версия DragonFly, как обычно, доступна в двух вариантах:
- в виде официального iso-образа с ftp-сервера проекта и его зеркал;
- и в виде сборки от GoBSD — т.н. DragonFly 1.2 Release Candidate, которая в данном случае появилась даже раньше официальной версии.
Какую выбрать — дело вкуса (формально различия между ними косметические. Однако лично у меня со сборкой от GoBSD раньше дело не ладилось, и потому я записал себя в стойкие приверженцы официоза. Так что на нем и задержим свое внимание.
Спрашивается — что же с этим диском делать? Штатный инсталлятор DragonFly (BSD Installer) в современном своем виде функции обновления не предусматривает. Можно, конечно, сохранить все свои настройки на отдельном носителе (например, на флэшке, — о необходимости сохранения данных напоминать не буду), и переустановить систему с нуля, после чего восстановить начальную конфигурацию. Но это — путь длинный и скучный. И примелем только в том случае, если хочется ознакомиться с новшествами установщика. Каковых, сразу скажу, очень мало, и касаются они только сетевой инсталляции, для настольного юзера не очень актуальной.
Но есть и другой, малозатратный, способ. Правда, таковым он окажется только в том случае, если дисковая разметка под файловые системы была выполнена так, как описывалось в статье про установку. То есть на отдельные разделы были вынесены не только ветви /var, /usr и /home, но и такие ветви, как /usr/src, /usr/local, /usr/X11R6, /usr/ports и /usr/ports/distfiles (при использовании системы портов из FreeBSD, для системы pkgsrc разметка будет чуть иная).
В этом случае процесс обновления окажется относительно простым. Для начала сохраняем все свои настроечные файлы из каталогов /etc, /root, /home и (в обязательном порядке) базу данных установленных пакетов — /var/db/pkg. При копировании следует использовать опцию -p для сохранения атрибутов доступа и принадлежности (конечно, если на носителе Unix like файловая система, для FAT/VFAT атрибуты потом придется восстанавливать вручную).
Теперь бестрепетно загружаемся с установочного диска, но вместо запуска инсталлятора авторизуемся как самый обычный root. Монтируем в каталог /mnt нашей «животворящей» файловой системы бывший корневой раздел с винчестера
$ mount /dev/ad0s1a /mnt
и, последовательно, ее главные ветви:
$ mount /dev/ad0s1d /mnt/var $ mount /dev/ad0s1e /mnt/usr
не затрагивая /home и файловых систем «второй генерации», от /usr/local, /usr/ports и глубже. И теперь остается только перенсти содержимое главных каталогов установочного диска в соответствующие ветви:
$ cpdup / /mnt $ cpdup /var /mnt/var $ cpdup /usr /mnt/usr $ cpdup /etc /mnt/etc $ cpdup /dev /mnt/dev
Обращаем сугубое внимание на две последние строки: на файловой системе LiveCD каталоги /etc и /dev представляют собой отдельные ветви, и потому их содержимое должно быть скопировано отдельно от корня.
Завершающий шаг — восстановление настроек из каталогов etc и root, а также базы данных пакетов var/db/pkg, с внешнего носителя (флэшки) в соответствующие ветви каталога /mnt. Очевидно, это можно сделать простым копированием:
$ mount /dev/da0s1a /mnt/mnt $ cp /mnt/mnt/etc/* /mnt/etc
и так далее. Правда, для этого флэшка должна нести на себе файловую систему UFS: в случае с FAT/VFAT для скопированных файлов потребуется еще и установиь правильные атрибуты доступа.
В результате у нас образуется свежеобновленная система DragonFly, сохранившая, однако, все ранее существовавшие настройки, а также — инсталлированные ранее (из портов или пакетов) приложения, скачанные непосильным трудом исходники и так далее, не говоря уже о пользовательских данных (которые, тем не менее, также желательно зарезервировать до начала обновления. А все затраты времени свелись к тем, за которые скопируются 250 примерно мегабайт с CD на винчестер.
К слову сказать — в одной из я писал, что в процессе экспериментов по оптимизации систему можно вполне довести до вполне неработоспособного (и, более того, неисправимого обычной пересборкой ядра и «мира») состояния. И даже обещал рассказать, как с этим бороться. Так вот, описанный способ обновления системы применим и в такой экстремальной ситуации. Позволяя выйти из нее с наименьшими потерями: просто восстановив содержимое главных каталогов базовой системы с установочного CD, не затрагивая портов, пакетов, исходников и прочего.
Как я уже говорил, описанный способ обеспечивает безболезненность обновления только при условии «правильной» дисковой разметки. А что делать, если при первой установке системы была принята схема разметки по умолчанию? Или просто лениво качать 80 Мбайт нового дистрибутива?
Есть способ, позволяющий обойтись без скачивания дистрибутива. И это — cvsup, тот самый, посредством которого мы ранее получили исходники ядра и системы. Однако прежде чем прибегнуть к нему, нужно разобраться с нумерацией версий и ветвями дерева исходников.
До недавнего времени существовала единственная официальная версия DragonFly (1.0A) и единое дерево ее исходников. Ныне же оно разделилось на две ветки — стабильную и разрабатываемую (примерный аналог stable и current из FreeBSD, соответственно). Версии первой ветки имеют в номере четную цифру «после запятой» (как ныне обсуждаемая 1.2), второй — нечетные.
В соответствии с этим изменились и тэги, которые следует указывать в конфиге для cvsup. Для получения исходников стабильной ветки, строка релиза приобретает следующий вид:
*default release=cvs tag=DragonFly_RELEASE_1_2_Slip
Таким образом мы получим именно те исходные тексты, из которых был собран релиз DragonFly 1.2. Если снять завершающий суффикс (slip). наше дерево исходников пополнится теми дополнениями, которые, вероятно, будут вноситься в стабильный релиз (вроде исправления ошибок).
Получение исходников разрабатываемой версии обспечивает тэг
*default release=cvs tag=DragonFly_Preview
От собранной из этих исходников системы опрометчиво было бы ожидать абсолютной стабильности. Однако это еще не фронтир разработки. Каковым являются исходники, получаемые посредством тэга HEAD.
Получив в том или ином виде исходники, остается только собрать из них систему — то есть выполнить процедуру сборки «мира» и ядра. Что можно сделать двояко: старым добрым gcc-2-95 (это по прежнему компилятор по умолчанию) или новомодным gcc-3.4.3. В первом случае — неизменно превосходный результат гарантирован. Но — «довольно жить по законам, данным Адамом и Евой», — и при втором варианте (он требует установки переменной
CCVER?=gcc34
в файле /etc/make.conf) никаких вредных последствий не обнаружилось. Правда, при флагах
-O1 -march=i686
к более жестким я прибегнуть не рискнул.
Сама по себе процедура была подробно . Так что просто напомню последовательность действий:
$ make buildworld $ make buildkernel KERNCONF=MYKERNEL $ make installkernel KERNCONF=MYKERNEL $ make preupgrade $ make installworld $ make upgrade
И после перезагрузки можно считать, что у вас на машине установлена новая версия DragonFly.