Любое знакомство с новой ОС, даже проводимое в сугубо экспериментальных целях, начинается с ее установки. А установка требует предмета оной - то есть дистрибутива. Вот с получения дистрибутива мы и начнем.

Генеральный путь для получения дистрибутива DragonFlyBSD, к сожалению (для обитателей необъятных просторов нашей Родины, в массе своей хорошим коннектом не избалованных) - один-единственный: из Сети. Правда, в утешение можно сказать, что там он доступен в нескольких вариантах.

Первый - это официальный релиз DragonFly, вышедший в июле 2004 г. и ныне по-прежнему доступный в виде bug-fix версии 1.0A на ftp-сервере проекта и ряде его официальных и неофициальных зеркал (список проверенных лично мною приведен в разделе ссылок Отличительная особенность официального релиза - то, что он собран посредством компилятора gcc старой, но надежной версии 2.95.X.

Второй вариант - это промежуточные стабильные версии, появляющиеся на тех же серверах с неопределенной периодичностью, но обычно не реже 2 раз в месяц. Стабильные версии, как и официальный релиз, собираются с помощью gcc-2.95.X.

Третий вариант - это текущие снапшоты проекта, выходящие очень часто (раз в несколько дней, иногда чуть ли не ежедневно). Они представлены двумя подвариантами: собранные gcc веток 2.95 и 3.4.X. В последнем случае используется обычно самая свежая версия компилятора (на момент сочинения этих строк - 3.4.3). Подвариант с gcc2 позиционируется как (полу-) стабильный, рассчитанный на практическое применение. Сборка же с gcc3 к реальному использованию не рекомендуется, предназначаясь для разработчиков и экспериментаторов. Однако, судя по личному опыту, и последний подвариант признаков какой-то особенной нестабильности обычно не обнаруживает. И к тому же более интересен с точки зрения тенденций грядущего. Так что я сформулировал бы это так: все снапшоты DragonFly стабильны, но некоторые стабильнее других. Хотя вероятность наткнуться на какой-либо неудачный снапшот из числа промежуточных и существует.

А вообще предубеждение против gcc 3-й ветки имеет исторические корни. Ведь на протяжении долгого времени она развивалась в основном в плане улучшения поддержки Си++, тогда как генерация чистого Си-кода не только не улучшалась, но, как считают многие авторитеты (среди коих - и Линус Торвальдс) даже ухудшалась. И потому критически важные программы операционок Unix-семейства, написанные на Си (а ядро и утилиты обрамления, как легко догадаться, попадают в их число), обычно рекомендовалось собирать посредством gcc-2.95.X.

Положение начало меняться в версиях gcc, начиная с 3.4.0. И ныне генерируемый ими Си-код, по свидетельствам знатоков, как минимум не хуже прежнего, созданного gcc-2.95.X. А если учесть, что старшие версии 3-й ветки позволяет еще и оптимизацию под современные процессоры (коих во времена 2-й ветки и в проекте не было), такие, как Pentium 4 и Athlon (в том числе отдельно - под Northwood, Prescott, Athlon XP и Athlon 64), то подвариант сборки DragonFly gcc3 начинает выглядеть предпочтительней и практически.

Наконец, четвертый вариант дистрибутива - в сборке от GoBSD - сайта компании, специально созданной для дистрибуции этой ОС и поддержки ее пользователей (и вообще формирования сообщества). Этот вариант носит имя GoBSD Distributions Preview и основан на одном из оригинальных стабильных снапшотов проекта, но несколько отличается комплектацией. В частности, он содержит тарбалл дерева pkgsrc, заимствованный из проекта NetBSD, и пакет bootstrap-pkgsrc, адаптирующий эту систему пакетного менеджмента для использования в DragonFly.

Надо заметить, что в текущей версии сборки от GoBSD (т.н. GoBSD Preview 2) были отмечены некоторые мелкие, но неприятные особенности, как-то: ошибки инсталлятора при разбиении диска, при некоторых условиях - некорректное завершение работы установленной системы, и так далее. Так что предпочтение все-таки следует отдать снапшотам с зеркал проекта DragonFly.

При этом мой личный опыт свидетельствует, что для установки на "боевую" рабочую машину, и тем более на "боевой" сервер (а DragonFly уже вполне пригодна и этом качестве, хотя этот вопрос я далее затрагивать не буду) нужно проявить здоровый консерватизм и выбирать последние стабильные снапшоты (файлы их образов маркированы как LATEST-STABLE), собранные с gcc-2.95.X. Тогда как для целей экспериментальных подойдет, скорее, текущий снапшот LATEST-GCC3. Подвариант же LATEST-GCC2 кажется наименее востребованным.

Впрочем, версиями "собирающего" компилятора при выборе нужного снапшота можно особенно и не заморачиваться: чем бы он ни был собран, в установленном виде доступными будут оба gcc. И хотя по умолчанию в качестве "рабочей" версии по умолчанию всегда выступает gcc2, это положение легко изменить (как - будет рассказано в следующей заметке цикла, когда нам это на самом деле понадобится). Так что всегда можно пересобрать систему тем или иным компилятором - по потребности.

Все описанные варианты дистрибутива доступны в Сети в виде iso-образов, сжатых утилитой bzip2 или, реже, gzip. Так что по получении такого файла его следует развернуть (посредством bunzip2 или gunzip, соответственно), "сболванить" любым доступным способом - и можно приступать к установке. Но сначала -

Прежде всего желательно сверить свои возможности, то есть наличное "железо", с потребностями новой ОС. Запросы DragonFly к оборудованию - примерно те же, что и у FreeBSD, как и совместимость с оным - повторюсь, что если отличия и есть, то в лучшую сторону. То есть все более-менее стандартное "железо" поддерживается, устройства, ориентированные на применение исключительно в Windows (win-модемы и win-принтеры) - не поддерживаются, со всякого рода экзотикой - как повезет. Однако с устройствами, критичными именно для установки - дисковыми контроллерами, видеокартами и т.д., - проблем быть не должно. Подробный список заведомо поддерживаемого оборудования можно найти на одной из страниц DragonFlyBSD Wiki - Supported Hardware

Интересно, что в DragonFly уже на стадии установки поддерживаются любые USB-накопители и ряд "чуждых" файловых систем (включая все варианты FAT и ext2/ext3. То есть если заранее озаботиться этой задачей и разместить нужное на флэшку или мобильный винчестер, то можно в ходе инсталляции читать, например, документацию, в том числе и русскоязычную. А можно даже записывать свои впечатления о ходе установки...

Поскольку наша инсталляция DragonFly, скорее всего, - экспериментальная, по умолчанию предполагается наличие на диске иной операционной системы - какого-либо представителя BSD-клана, одного из дистрибутивов Linux или даже, не к ночи будь помянут, Windows. Конечно, хорошо было бы устанавливать новую систему на отдельный винчестер - но такая возможность предоставляется не всегда. Так что будем исходить из того, что на диске имеются разделы с некими данными, которую следует сохранить.

Программа установки DragonFlyBSD (BSD Installer) в современном ее виде допускает инсталляцию этой системы либо на диск целиком, либо на существующий раздел (слайс, в BSD-терминологии), имеющий идентификатор типа файловой системы 165 в десятичном исчислении (приписанный операционной системе FreeBSD). Конечно, при наличии неразбитого дискового пространства и минимум одной свободной позиции в MBR под первичный раздел (или просто существующего раздела, которым вы готовы пожертвовать на благо DragonFly) это можно обойти - и в следующей части этой статьи я расскажу, как. Однако пользователям, не имевшим ранее дела с программой fdisk от BSD-систем, лучше озаботиться созданием такого раздела заранее. Что легко сделать из Linux - если такового не установлено, то просто загрузившись с любого дистрибутива LiveCD, вызвать fdisk, создать его средствами первичный раздел и присвоить ему нужный идентификатор (в шестнадцатеричном виде, привычном пользователями Linux, он будет равен A5).

Выше я говорил о необходимости минимум одной свободной (или освобождаемой при жертвоприношении раздела) записи в MBR под первичный раздел. Это - почти обязательное требование. Теоретически, начиная со снапшотов конца 2004 г., DragonFly можно поставить и с логический раздел Extended Partition. Однако это уж точно придется делать вручную - BSD Installer такового просто не увидит...

И еще очень важно знать, какие именно первичные разделы (в том числе и объявленные как расширенные и содержащие логические тома) на диске задействованы под файловые системы Windows или Linux, иначе их очень легко будет уничтожить при разметке слайса для DragonFly.

Сколько места выделить под новую ОС - зависит опять-таки от возможностей и потребностей. Сама по себе базовая система DragonFlyBSD очень компактна, и занимает немного больше 200 Мбайт. Однако в это число не входят ни исходники системы, ни дополнительное программное обеспечение, устанавливаемое из пакетов или собираемое из портов, ни, тем более, исходники для работы последней. И потому минимальный рекомендуемый объем дискового пространства в документации определяется примерно в 6 Гбайт. А для того, чтобы в полной мере оценить прелести системы портов или pkgsrc, этих гигабайт желательно иметь по крайней мере 10. И это - не считая пользовательских данных - сколько места отвести под них, вы знаете лучше меня.

И, наконец, последнее: перед загрузкой с инсталляционного диска установите в BIOS своей машины время по Гринвичу (GMT или UTC). Даже при отсутствии постоянного подключения к Сети это даст некоторые дополнительные удобства. Ну а при наличии - вы получите в свое распоряжение личную службу точного времени.

Пользователям, не имевшим ранее опыта общения с BSD-системами, следует до начала установки внимательно ознакомиться с правилами номенклатуры дисковых накопителей и их разделов, принятых в ОС этого семейства, а также особенностями BSD-стиля дисковой разметки. Вопросы эти подробно рассмотрены в любой книге или руководстве по FreeBSD (и в DragonFly Handbook). Так что здесь остановлюсь на них вкратце.

Дисковые накопители с ATA-интерфейсом (точнее, конечно, не накопители, а файлы соответствующих устройств, но для нас это сейчас не важно) в DragonFly (как и во FreeBSD) именуются так (табл. 1).

Таблица 1. Номенклатура дисковых накопителей

В DragonFly по умолчанию принята т.н. статическая нумерация дисковых устройств: то есть файл устройства Slave на 2-м канале будет носить имя ad3, даже если он является единственным дисков в машине.

Как известно, диск может быть разбит на 4 первичных раздела. В BSD-терминологии они обычно именуются слайсами (slices), хотя в DragonFly этот термин не проводится последовательно, тем не менее, имена соответствующих устройств будут такими (табл. 2).

Таблица 2. Номенклатура первичных разделов (слайсов)

Обращаем внимание - слайсы, в отличие от дисков, нумеруются, начиная с единицы. Нумерация слайсов определяется не порядком их создания, а номером записи в таблице разделов MBR: то есть на диске может существовать только единственный слайс ad0s4 (другое дело - зачем это нужно), прочие теоретически возможные слайсы при этом будут помечены как UNUSED (неиспользуемые).

Наконец, внутри слайса создаются разделы под собственно файловые системы BSD (partitions в терминологии FreeBSD), или подразделы (subpartitions), как они называются в DragonFly: это - некие аналоги логических разделов в Windows и Linux. В отличие от FreeBSD, в DragonFly слайс может содержать до 16 подразделов, имена соответствующих им файлов устройств маркируются литерами латинского алфавита - ad0s1a и так далее. Назначение первых трех подразделов жестко фиксировано: они предназначены для корневой файловой системы, раздела подкачки и описания слайса целиком, прочие же могут использоваться под отдельные ветви файловой системы, типа /usr, /var и так далее (табл. 3)

Таблица 3. Номенклатура подразделов (subpartitions) слайса

Слайс может быть размечен как единственный подраздел - именно так происходит при автоматической разметке соответствующей утилитой disklabel; впрочем, в ходе инсталляции пользователю, скорее всего, дела с ней иметь не придется. В этом случае к нему нужно обращаться так: ad0s1c (вот зачем нужна зарезервированная запись в таблице разделов). А может и не содержать подразделов вообще - и тогда его именем будет просто ad0s1. Именно таким образом могут выглядеть в ОС BSD-семейства разделы, несущие чуждые ей файловые системы (от Windows или Linux).

На иллюстрациях к последующим разделам статьи можно будет увидеть дисковое устройство с именем da0. В принципе, имена типа da# соответствуют винчестерам со SCSI-интерфейсом. Таковых в обычной пользовательской машине, скорее всего, нет. Однако накопители с любым интерфейсом, кроме ATA, также предстают перед системой в качестве винчестером SCSI, в том числе и столь распространенные ныне флэшки, карты памяти цифровых камер, внешние диски, подключенные к USB или FireWire (почему так - тайна сия велика есть). Так вот, для подготовки рисунков, иллюстрирующих процесс дисковой разметки, я манипулировал с самой обычной флэшкой - не на рабочем диске же было это делать? Хотя в принципе скриншоты консоли в DragonFly можно было бы сделать даже во время первичной инсталляции - и со временем я надеюсь показать, как (хотя, наверное, и не в этой статье).

И последнее, имеющее отношение к терминологии. Пользователь Linux уже давно привык к разнообразию файловых систем, поддерживаемых этой операционкой в качестве "родных" (native). Однако в DragonFly в роли нативной выступает одна-единственная файловая система - UFS, принятая также во FreeBSD (Unix File System, хотя под этим именем известны и файловые системы иных операционок, отличные по устройству от данной). Теоретически с конца 2004 года поддерживается и ее усовершенствованный, 64-разрядный, вариант - UFS2 ("умолчальная" файловая система FreeBSD 5-й ветки), однако практически ею можно воспользоваться только при ручной установке - BSD Installer еще ничего не знает о ее существовании.

Установочный диск DragonFly - загрузочный, несет на себе инсталлятор собственной конструкции. Кроме того, он являет собой полноценный LiveCD, что допускает выполнение всех необходимых действий, предваряющих установку. Однако начну по порядку.

На первой стадии загрузки появляется обычное для FreeBSD меню выбора режимов загрузки - "умолчального", с отключенным ACPI, в однопользовательском режиме, и так далее. Отличие только в логотипе - стрекоза вместо демона с вилами. Никаких проблем с загрузкой на подручных конфигурациях (весьма, нужно сказать, разнообразных) не возникает. В отличие, опять же, от FreeBSD, которая в "умолчальном" режиме категорически отказывалась грузиться на моей Toshiba, а при отключении ACPI грузилась через раз.

В ходе загрузки файловая система установочного CD монтируется как корневая в оперативной памяти. Для всякого рода установочных действий в ней предназначается каталог /mount.

По завершении загрузки системы поступает предложение авторизоваться. Возможных аккаунтов - два: root и installer, оба беспарольные. Выбор того или иного предопределяет дальнейшие действия - впрочем, почти в любой момент времени можно переавторизоваться.

Аккаунт root предназначен для ручной установки системы. После его регистрации появляется приглашение командной строки (полноценный tcsh), из которой и выполняются все необходимые действия, как то:

1. создание первичного дискового раздела для установки DragonFly (слайса, в терминологии FreeBSD) с помощью команды fdisk;
2. разбиение слайса на разделы под отдельные файловые системы DragonFly (корневую, для каталогов /tmp, /var, /usr и так далее, по потребности), а также выделение пространства под своппинг: все это делается посредством команды disklabel;
3. создание собственно файловых систем с помощью команды newfs;
4. создание в каталоге /mount подкаталогов - точек монтирования для новообразованных файловых систем;
5. собственно монтирование их командой mount куда следует - будущего корня в /mount, грядущих /tmp, /var, /usr - в /mount/tmp, /mount/var, /mount/usr, соответственно, и так далее;
6. перенос содержимого необходимых каталогов с установочного CD на подготовленные файловые системы винчестера - / в /mount, /var в /mount/var, и так далее; делается это не простым копированием, а специально для этого предназначенной утилитой cpdup;
7. постинсталляционные действия - установка требуемых прав доступа для некоторых каталогов, удаление ненужных более временных файлов, редактирование необходимых конфигурационных файлов (например, /mount/etc/fstab, /mount/etc/rc.conf, и так далее).

Все сказанное звучит несколько устрашающе, хотя ручная установка DragonFly не требует от пользователя чего-либо сверхъестественного. Тем более что весь процесс очень подробно описан в Handbook'е. Однако дело это весьма занудное - особенно разбиение диска на слайсы и создание разделов под файловые системы, связанные с вычислениями (fdisk и disklabel не являют собой идеала дружественности к пользователю) и требующие большой аккуратности.

Так что лучше по возможности использовать штатный установщик дистрибутива. Однако и при этом, как будет показано ниже, в некоторых случаях может возникнуть необходимость обращения к root-аккаунту для выполнения отдельных действий (например, выделения дискового раздела), и потому иметь представление о его возможностях не вредно.

И еще: дистрибутивный диск DragonFly являет собой настоящий LiveCD, и с помощью root-режима после установки системы можно выполнять всякого рода аварийно-спасательные работы, а также некоторые мероприятия по настройке уже установленной системы.

Второй вариант авторизации - под аккаунтом installer. Это автоматически вызывает штатный установщик DragonFly - BSD Installer, служащий также для начального конфигурирования системы. Именно он и будет предметом дальнейшего рассмотрения.

Как уже говорилось в предыдущей заметке, BSD Installer - программа, созданная в рамках самостоятельного проекта, и предназначенная для установки любых BSD-систем. Однако пока она оказалась востребованной именно для установки DragonFly (и еще - в LiveCD системе, FreeSBIE, где позволяет превратить ее в полноценную FreeBSD 5-й ветки). Однако именно в DragonFly эта программа показывает себя во всей красе.

В дистрибутиве DragonFly применяется BSD Installer с псевдографическим фронт-эндом, основанным на библиотеке ncurces. Он несколько напоминает по стилю традиционную sysinstall из FreeBSD, но производит впечатление более логичного и понятного, хотя и уступает (пока?) тому в функциональности. Тем не менее, как и sysinstall, BSD Installer - позволяет не только инсталлировать базовую систему, но и выполнить основные ее настройки, Причем не только во время первичной установки, но и, с некоторыми оговорками, и впоследствии.

Фактически BSD Installer выполняет все те действия, которые пользователь производит при ручной установке сам, но - в полуавтоматическом режиме, предоставляя через меню выбор из нескольких предопределенных вариантов. Что, понятно, менее гибко, но существенно легче. Кроме того, он допускает (до некоторого момента) отказ от совершенных действий и возврат на исходные позиции, позволяя избежать необратимых ошибок (например, при разметке диска).

Для начала, сразу после регистрации с аккаунтом installer, установщик предлагает следующие варианты выбора (рис. 1):

1. установка;
2. конфигурирование ранее установленной системы;
3. утилиты LiveCD;
4. выход в среду LiveCD;
5. перезагрузка.

Рис. 1. Начальное меню BSD Installer

На первом этапе установки интерес представляют пункты 1 и 3. В частности, посредством 3-го пункта можно было бы теоретически выполнить разбиение диска, однако в настоящее время здесь допускается только создание первичного раздела (BSD-слайса) на весь диск целиком. Как обойти эту сложность - я скажу чуть позже.

А пока обратимся к первому пункту - установке системы, следующим шагом подтвердим свой выбор - и попадаем в меню выбора диска (рис. 2).

Рис. 2. Меню выбора диска

Поскольку мы предположили, что таковой имеется в единственном экземпляре, выбирать особенно не из чего. А вот дальше предлагается создать на диске раздел под DragonFly, и здесь выбор уже есть: использовать под установку DragonFly диск целиком (entire disk) или его часть рис. 3). Так как мы не собираемся отказываться от ранее установленной системы, первый вариант нас, скорее всего, не устраивает - хотя при нем все происходит очень просто (почему я говорил о желательности отдельного диска для DragonFlyBSD. Да и второй тоже походит не во всех случаях: штатными средствами можно создать слайс только на все оставшееся неразбитым пространство.

Рис. 3. Выбор типа разбиения диска

Если, однако, мы готовы отдать все остатки диска на растерзание DragonFly, все просто: соглашаемся со вторым вариантом, и, после подтверждения уверенности в своей правоте (рис. 4), получаем BSD-слайс соответствующего размера.

Рис. 4. Запрос на подтверждение правильности выбора раздела

Перед положительным ответом на вопрос с рис. 4 неплохо еще раз подумать: все содержимое раздела, если оно имелось, будет потеряно (произойдет не просто изменение типа раздела, но и "обнуление" его начального сектора командой

$ dd if=/dev/zero of=/dev/ad#s?

В чем любознательный пользователь может легко убедиться, просмотрев вывод сообщений инсталлятора на первой виртуальной консоли.

Если же часть неразбитого пространства требуется сохранить таковым для последующего использования в каких-либо целях (и если имеется резерв записей под первичные разделы), придется действовать иначе. Благо, оказывается, что установочный LiveCD нашей системы сохраняет свои "живительные" свойства и после запуска инсталлятора. Предоставляя в расположение пользователя шесть свободных виртуальных консолей из восьми возможных (на второй запущен установщик, на первую выводятся его сообщения). И можно, перейдя в любую из них, авторизоваться там как root (по прежнему без пароля), создать нужный раздел вручную - с помощью программы fdisk. Правда, в BSD-системах этот инструмент не являет собой верх удобства, требуя (даже в интерактивном режиме) явного задания начала и конца раздела в физических (по 512 байт) блоках. И, соответственно, некоторых вычислений.

Правда - вот что LiveCD животворящий творит - и вычислитель оказывается под рукой, в лице простой в использовании утилиты bc. А поскольку лимит консолей далек от исчерпания - никто не мешает запустить его параллельно и выполнить необходимые расчеты. После чего командой

$ fdisk -i /dev/ad0

создать раздел нужного размера на неразбитом пространстве в интерактивном режиме - то есть последовательно отвечая на вопросы программы.

Сначала, после вывода информации о текущем разбиении диска, последует вопрос, а хотим ли мы изменить первый из первичных разделов. Вероятно, ответ должен быть отрицательным - ибо этот раздел, скорее всего, занят под Windows, Linux или иную BSD (впрочем, соответствующие сведения будут выведены на экран, нужно только внимательно их читать).

Затем аналогичный вопрос будет задан касаемо второго и последующих первичных разделов (как известно, более четырех их на одном диске быть не может). Отвечать также следует отрицательно - до тех пор, пока вопрос не коснется раздела, помеченного в экранном виде как UNUSED (неиспользованный) - это и будет то самое свободное дисковое пространство, не приписанное еще ни к одной ОС. Или - существующего раздела, обреченного в жертву. Тут мы соглашаемся на внесение изменений - совершаем их, отвечая на новую серию вопросов.

Первым из них будет запрос на ввод, второй- это ручное создание слайсов (при существующей уже разметке сначала будет вопрошаемо, а хотим ли мы этого - с отрицательным ответом по умолчанию). Для этого сначала запрашивается идентификатор типа файловой системы (по умолчанию стоит ID существующего раздела или 0 - для неразмеченного пространства). Тут следует руками указать его десятичное значение (165 - идентификатор FreeBSD/DragonFly). Затем запрашивается стартовый сектор - очевидно, первый сектор этого раздела, - и размер размер раздела в блоках по 512 байт - его следует вычислить посредством bc.

После этого будет предложено точно специфицировать начало и конец слайса. Если отказаться - они будут взяты из предыдущих определений, если согласиться - нужно будет указать первые и последние цилиндр, головку, сектор. Каковые и будут выведены в виде

sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
 start 0, size 260000 (126 Meg), flag 0
 beg: cyl 0/ head 0/ sector 1;
 end: cyl 126/ head 60/ sector 32

Подтвердив свои действия положительным ответом на вопрос

Are we happy with this entry? [n] y

следует отказаться от изменений остальных записей таблицы разделов (если таковые еще остались). После чего будет задан последний вопрос - подтверждение на выполнение собственно разметки:

Do you want to change the active partition? [n]

При положительном ответе на него все сделанные изменения вступят в силу (и на ранее размеченном диске при ошибке можно будет распроститься с его содержимым). Так что следует предварительно просмотреть все ранее введенное - благо, это легко сделать пролистыванием буфера истории виртуальной консоли, перейдя в режим его просмотра, нажав клавишу ScrollLock (а сам просмотр выполняется как клавишами PageUp/PageDown - поэкранно, так и стрелками Up и Down - построчно). И при обнаружении ошибки отказаться от изменений и запустить команду fdisk по новой. Впрочем, из нее можно в любой момент выйти без последствий и стандартным образом - комбинацией клавиш Control>+C.

Необходимость в ручном разбиении диска возникнет и на "чистом" диске в том случае, если мы хотим отдать под DragonFly более одного первичного раздела (в ближайшей интермедии я расскажу, почему это может быть целесообразно). В этом случае второй слайс создается точно также, как и первый.

Порядок создания дисковых разделов средствами fdisk подробно описан на ее man-странице - благо она во время инсталляции доступна с LiveCD. А вообще-то, как я уже говорил, если поступиться принципами, проще всего создать слайс (и тем более слайсы) для DragonFly заблаговременно - средствами любого наличного LiveCD с Linux. А при наличии установленной FreeBSD это легко сделать средствами ее sysinstall.

По завершении ручной разметки слайса (или слайсов) нужно сделать его доступным для BSD Installer'а. Для чего придется вернуться в его начальное меню, выбрать в нем пункт Exit to LiveCD (см. рис. 1) и авторизоваться как installer заново.

Тем или иным способом создав первичный раздел, выбираем его в соответствующем меню для разбиения на подразделы (subpartitions). Вариант, предлагаемый по умолчанию, таков (рис. 5):

Рис. 5. Создание дисковых подразделов, нормальный режим

Эта схема вполне разумна, и для пользователя, ранее с BSD системами дела не имевшего, может быть принята. Если он, тем более, собирается пользовать DragonFly сугубо для экспериментальных целей. Разве что при недостатке места уменьшить раздел под /usr (вплоть до минимума в 4096 Мбайт - почему я и говорил ранее, что инсталляция DragonFly требует около 6 Гбайт дискового пространства) и swap (при памяти от 512 Мбайт он практически не задействуется).

Однако если планируется (или хотя бы допускается) применение DragonFly в качестве "боевой" платформы - к вопросу разметки подразделов нужно подойти со всей ответственность. Собственно, из рук вон плохая дисковая разметка - чуть ли не единственная причина, делающая неизбежной переустановку "с нуля" любой операционки POSIX-семейства (все другие проблемы могут быть решены терапевтическими методами), и DragonFly тут не исключение. Почему и дело это выделено в отдельное производство - этой теме посвящен специально следующий раздел.

Пока же только замечу, что кроме нормального режима разметки подразделов, проиллюстрированного на рис. 5, существует еще и т.н. "режим эксперта" (рис. 6). В котором, помимо указания размера разделов, для отдельных из них можно еще и включить или выключить режим Softupdates, а также определить индивидуально размер блока и фрагмента файловой системы. Процедура создания последней (то есть исполнение команды newfs или, в терминах DOS/Windows, форматирование) совмещена в меню BSD Installer с разметкой разделов и осуществляется в один прием с ней - по выбору Accept and Create, вызывающим последнее предупреждение, с которым "пользователь соглашается и форматирование совершается".

Рис. 6. Создание дисковых подразделов, режим эксперта

По окончании создания файловой системы (а для больших разделов он может затянуться) задается вопрос - приступить ли к переносу файлов базовой системы. В отличие от большинства дистрибутивов Linux (а также FreeBSD и прочих BSD-систем), при этом не происходит никакой распаковки архивов или развертывания пакетов. Просто файловая система LiveCD (находящаяся в этот момент, напомню, в оперативной памяти) со всем ее содержимым - каталогами, подкаталогами и отдельными файлами) копируется на соответствующие разделы ранее созданного слайса, подмонтированные в виртуальный каталог /mnt: корень - в корень, /usr - в /usr, и так далее. Правда, не обычной командой cp, а специально для того предназначенной утилитой cpdup, обеспечивающей полную идентичность файловой структуры источника и приемника (включая воспроизведение жестких и символических ссылок, файлов устройств, атрибутов доступа и принадлежности). Это важно помнить при аварийно-спасательных работах, о чем будет подробнее говориться в следующей статье.

Так вот, при согласии пользователя (а куда ему деваться - иначе никакой установки и не будет) начинается такой процесс переноса файлов. Причем, в отличие от sysinstall из FreeBSD, никакого выбора пакетов базового комплекта перед этим не предлагается. И это, конечно, минус - в результате пользователь оказывается "счастливым" обладателем, например, системы безопасности Kerberos или info-документации, возможно, на фиг ему не нужных. Да и скорости переноса файлов (должен сказать, не быстрой) это никак не способствует. Но уж что выросло - то выросло... А от ненужных частей базовой системы (как тот же Kerberos) можно будет избавиться в дальнейшем - об этом речь пойдет в следующей статье.

Под занавес начальной установки - предложение установить загрузчик, точно такой же loader, что и во FreeBSD. И установить его можно опять же в загрузочный сектор диска или слайса. В первом варианте - прописывание BSD'шного loader'а в MBR диска - он позволяет осуществить мультисистемную загрузку с любого первичного раздела (на котором собственные средства загрузки имеются, конечно). Второй же вариант потребует обеспечения загрузки DragonFly средствами Lilo или GRUB, что сделать не сложнее, чем для FreeBSD, но к теме нашего сегодняшнего разговора отношения не имеет. Тем более, что BSD Loader, не смотря на свою внешнюю простоту и непрезентабельность, успешно справляется с загрузкой своей родной операционки (еще бы!), а также Windows, Linux и любой другой BSD. При условии, что их собственные загрузчики лежат в загрузочных секторах первичных дисковых разделов - но и об этом разговор еще впереди.

Собственно установка окончена - предлагается либо перейти к конфигурированию системы, либо перезагрузиться (можно и вернуться на первую страницу инсталлятора). Нас, конечно, будет интересовать вопрос начального конфигурирования. Но сначала - обещанная

У пользователя со стажем работы, например, в Linux или какой-либо BSD-системе, скорее всего, сложились уже собственные представления об идеальной схеме разметки разделов. И представления эти, с некоторыми коррективами, вполне применимы и к DragonFly. Однако позволю себе осветить свои представления по этому вопросу - во-первых, ввиду важности, а во-вторых - потому что особенности текущего состояния BSD Installer делают ошибки в дисковой разметке весьма трудноустранимыми его средствами. Ну и вообще для DragonFly этот вопрос имеет ряд специфических аспектов.

Итак - сакраментальный российский вопрос - что делать? (при разметке диска), и кто виноват? (если "опять все не получилось!" - как сказал в отчаянии хирург, кромсая большим медицинским скальпелем внутренности пациента после неудачной операции аппендикса).

Правда, на второй вопрос ответить легко: виноват, в 99 случаев из ста, сам хирург, то есть пользователь, устанавливающий систему. А вот первый - это действительно вопрос, сродни Гамлетовскому.

Существует широко известный стандарт FHS (Filesystem Hierarchy Standart), описание которого доступно в русском переводе благодаря Виктору Костромину. Хотя его конкретная реализация и не столь уж общепризнанна, как это кажется его авторам (или, скорее, как бы им хотелось), положенные в его основу принципы вполне можно взять на вооружение при определении стратегии дисковой разметки.

В основу FHS положена пара альтернатив:

1. противопоставление неизменяемых и изменяемых файловых систем;
2. обособление файловых систем неразделяемых и разделяемых.

Контент неизменяемых файловых систем создается при инсталляции ОС ее первичной настройке, и в дальнейшем не претерпевает модификации. По крайней мере, без участия администратора - а тот должен прибегать к ней лишь при наличии веских причин. Типичный пример - корневая файловая система. Такая ее ветвь, как /usr, также по хорошему должна бы быть неизменяемой, и, как мы увидим дальше, в BSD, в отличие от Linux, это легко реализовать.

Изменяемые файловые системы содержат не только пользовательские данные (постоянное модифицирование которых очевидно). Это и такие ветви, как /tmp и /var: ведь в эти каталоги запись осуществляют не столько сами пользователи, сколько запускаемые ими программы, наследующие в подавляющем большинстве случаев эффективные ID своих хозяев.

К изменяемым ветвям файлового древа можно отнести также каталоги /usr/local и, в ряде случаев, /usr/X11R6. Конечно, инсталляция дополнительного программного обеспечения (для которого и предназначен /usr/local) - обычно привилегия администратора (и это подчеркивается атрибутами доступа к этим каталогам). Однако у пользователя, ведущего активную софтверную жизнь (а таких среди истинных POSIX'ивистов - большинство) это происходит достаточно часто. Что же касается