FreeBSD - это современная операционная система для настольных компьютеров, ноутбуков, серверов и встраиваемых систем с поддержкой большого количества платформ.

В основе FreeBSD лежит операционная система <<4.4BSD-Lite>> Калифорнийского Университета (Беркли) с некоторыми усовершенствованиями из <<4.4BSD-Lite2>>. Также она косвенно базируется на 386BSD (BSD Net/2, перенесённой на платформу i386TM Уильямом Джолитцем (William Jolitz)), хотя от того первоначального кода осталось очень мало.

FreeBSD используется компаниями, Интернет-провайдерами, научными работниками, профессионалами в вычислительной технике, студентами и рядовыми пользователями по всему миру для работы, образования и отдыха.

Для более детального знакомства с FreeBSD обратитесь к Руководству по FreeBSD.

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

Да. Эти ограничения не касаются аспектов использования кода, но главным образом описывают отношение к Проекту FreeBSD. Текст лицензионного соглашения доступен здесь, и вкратце он может быть изложен следующим образом:

Многие из нас вкладывают в проект значительные усилия и определённо были бы не против получения финансовой поддержки, но требовать её мы не будем. Мы надеемся, что наша основная и самая значительная <<миссия>> - предоставить код всем желающим, для любых целей, так чтобы он нашел самое широкое применение и принёс наибольшую пользу. Это, на наш взгляд, одна из самых фундаментальных целей Free Software, которую мы с энтузиазмом поддерживаем.

Часть исходного кода нашей системы, подпадающая под действие GNU General Public License (GPL) или GNU Library General Public License (LGPL), имеет несколько больше ограничений, хотя и представляет собой навязывание доступа к исходным текстам, а не наоборот, как обычно. Из-за дополнительных сложностей, которые могут возникнуть в случае коммерческого использования программного обеспечения GPL, мы стараемся, где только это возможно, заменить подобное программное обеспечение аналогичным, но подпадающим под менее строгую лицензию FreeBSD.

Для большинства людей, да. Но этот ответ не так уж однозначен.

Большинство пользователей на самом деле не используют операционную систему. Они работают с приложениями. Именно прикладные программы и используют операционную систему. FreeBSD разработана для того, чтобы дать надежное и полнофункциональное окружение для приложений. Она поддерживает широкий спектр Web-браузеров, офисных пакетов, программ для работы с электронной почтой, графических пакетов, программных сред, сетевых серверов и многое другое. Большинство этих приложений могут быть получено из Коллекции Портов.

Если приложение доступно только для одной операционной системы, то нельзя всего лишь заменить эту операционную систему. Однако есть вероятность, что похожая программа существует для FreeBSD. В качестве сервера для офиса, или сервера Интернет, или надежной рабочей станции FreeBSD практически всегда справится со всем, что вам нужно. Многие пользователи по всему миру, включая как новичков, так и опытных администраторов UNIX(R), используют FreeBSD в качестве своей единственной настольной операционной системы.

Пользователи при переходе на FreeBSD с другого варианта UNIX(R) найдут для себя FreeBSD очень похожей. Пользователей Windows(R) и Mac OS(R), напротив, может заинтересовать PC-BSD, дистрибутив на основе FreeBSD. Пользователям, которые не использовали до этого UNIX(R), понадобится затратить дополнительное время на изучение подхода UNIX(R) к работе. Этот FAQ и Руководство по FreeBSD являются прекрасным способом начать это изучение.

Следует отметить, что слово <<free>> используется здесь в двух смыслах: один означает <<бесплатно>>, а другой <<делать всё, что хотите>>. За исключением пары вещей, которые вы не можете делать с FreeBSD, например, претендовать на то, что являетесь её разработчиком, на самом деле можно делать с ней всё, что вам заблагорассудится.

Джеймс Ховард (James Howard) создал хорошее описание истории и различий между различными проектами под названием Семейное древо BSD, в котором даётся подробный ответ на этот вопрос. Некоторая информация там устарела, но историческая часть остаётся точной.

Многие из проектов семейства BSD обмениваются изменениями и готовым кодом даже сегодня. Все они происходят от общего предка.

Цели проекта FreeBSD описаны выше в Вопрос: 1.2. Цели других наиболее известных проектов семейства BSD можно кратко описать так:

На любом этапе разработки FreeBSD может существовать несколько параллельных веток. Релизы 10.X выполняются из ветки 10-STABLE, а релизы 9.X выполняются из 9-STABLE.

До выпуска 9.0 линейка 9.X была известна как -STABLE. Однако к моменту выхода 11.X линейка 9.X получит статус <<extended support>> (расширенная поддержка), и исправления будут вноситься только для серьезных проблем, к примеру исправления, связанные с безопасностью.

Версия 11.1, дата выхода Январь 2014, является последним релизом в ветке 10-STABLE. Версия 10.4, дата выхода Сентябрь 2013, является последним релизом в ветке 9-STABLE.

Если вкратце, то ветка -STABLE предназначена поставщикам услуг Internet, корпоративным пользователям, а также всем тем, кому в первую очередь нужна надёжность и минимальное количество отличий от последнего релиза по сравнению с новыми (и, возможно, ненадёжно работающими) возможностями последнего снэпшота -CURRENT. Релизы можно делать из любой ветки, но -CURRENT предназначен для пользователей, которые готовы к постоянным (по сравнению со -STABLE) изменениям в работе системы.

Релизы делаются раз в несколько месяцев. Хотя многие стараются отслеживать актуальное состояние исходных текстов FreeBSD (обратите внимание на вопросы о FreeBSD-CURRENT и FreeBSD-STABLE), делать это не обязательно, так как исходные тексты постоянно меняются.

Более полную информацию о релизах FreeBSD можно получить на странице Информации о подготовке релизов и на странице Справочника release(7).

FreeBSD-CURRENT - это версия операционной системы, находящаяся в стадии разработки, которая должна потом стать новой веткой FreeBSD-STABLE. Таким образом, она представляет реальный интерес только для разработчиков системы и её фанатов. Обратитесь к соответствующему разделу Руководства для прояснения деталей работы с -CURRENT.

Пользователям, не знакомым с FreeBSD, не следует использовать FreeBSD-CURRENT. Эта ветвь зачастую меняется очень быстро и иногда из-за ошибок может быть не работоспособна. Те, кто используют FreeBSD-CURRENT, должны быть в состоянии изучить проблему, найти причину и сообщить о этом.

Из веток -CURRENT и -STABLE выпускаются снэпшоты FreeBSD. Их предназначение:

Не утверждается, что всякий снэпшот -CURRENT имеет качество <<готового продукта>>. Если нужна стабильно работающая и полностью оттестированная система, то придерживайтесь использования полных релизов или используйте снэпшоты -STABLE.

Снэпшот-релизы доступны непосредственно отсюда.

Официальные снэпшоты постоянно генерируются для всех активно разрабатываемых веток.

После того, как была выпущена FreeBSD 2.0.5, разработка FreeBSD разделилась на две части. Одна ветка получила название -STABLE, а другая -CURRENT. FreeBSD-STABLE предназначена для провайдеров услуг Интернет и других коммерческих пользователей, для которых неожиданные изменения или экспериментальные возможности весьма нежелательны. В неё вносятся только хорошо оттестированные исправления и другие небольшие последовательные усовершенствования. С другой стороны, FreeBSD-CURRENT являлась единой веткой, не разрываемой с момента выхода версии 2.0 и ведущей к 11.1-RELEASE и последующим релизам. Для получения более подробной информации по веткам обратитесь к разделу статьи << Подготовка релизов FreeBSD: Создание ветки релиза>>. Статус веток и расписание предстоящих релизов можно получить на странице Информация о подготовке релизов.

Активно разрабатываемой веткой -STABLE является 11.1-STABLE. Последним релизом в ветке 11.1-STABLE является 11.1-RELEASE, выпущенный Январь 2014.

Активно разрабатываемой веткой -CURRENT является ветка 11-CURRENT, которая движется к созданию следующего поколения FreeBSD. Прочтите ответ на вопрос Что такое FreeBSD-CURRENT? для получения более подробной информации об этой ветке.

Группа Выпуска Релизов FreeBSD <re@FreeBSD.org> выпускает новую старшую версию FreeBSD в среднем каждые 18 месяцев и младшие версии каждые 8 месяцев. Даты релизов обычно объявляются заранее, так что те, кто работает над системой, знают, когда их проекты должны быть закончены и протестированы. Период тестирования предшествует выходу каждого релиза, для того, чтобы удостовериться в том, что добавление новых возможностей не повлияло на стабильность работы релиза. Многие пользователи расценивают такую осторожность как одну из приятнейших черт FreeBSD, хотя необходимость дожидаться -STABLE для получения всех этих новых возможностей может несколько разочаровывать.

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

Для тех, кому нужно или хочется, еженедельно выпускаются бинарные снапшоты, как описано выше.

Решения, которые касаются ключевых моментов в проекте FreeBSD, такие, как общее направление развития проекта или кто может добавлять код к дереву исходных текстов, принимаются основной командой разработчиков (Core Team), состоящей из 9 человек. Также существует многочисленная группа, состоящая из более чем 350 так называемых коммиттеров (committers), которые могут вносить изменения прямо в дерево исходных текстов FreeBSD.

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

Все основные релизы FreeBSD доступны по FTP с FTP-сервера FreeBSD:

Информация о получении/приобретении FreeBSD на CD, DVD и других носителях доступна в Руководстве.

База данных всех сообщений пользователей о проблемах может быть запрошена с помощью нашего Web-интерфейса.

Можно использовать Web-интерфейс для отсылки сообщений об ошибках через браузер.

Перед тем, как посылать сообщение об ошибке, прочтите статью Составление сообщений о проблеме во FreeBSD о том, как писать хорошие сообщения об ошибках.

В рамках проекта создан широкий спектр документации, которая доступна on-line по следующей ссылке: http://www.FreeBSD.org/docs.html. Кроме того, в Библиографии в конце этого FAQ и в Руководстве имеются ссылки на другие рекомендуемые для чтения книги.

Да. Документация имеется в нескольких различных форматах и упакованная разными способами на FTP-сервере FreeBSD, и находится она в каталоге /pub/FreeBSD/doc/.

Документация подразделяется на категории различными способами. Это включает:

После выбора формата и способа компрессии, сгрузите упакованные файлы, распакуйте их, а затем скопируйте документацию в соответствующие места.

Например, версия FAQ в виде отдельных HTML-файлов, упакованная при помощи bzip2(1), находится в файле doc/ru_RU.KOI8-R/books/faq/book.html-split.tar.bz2. Для сгрузки и распаковки этого файла наберите:

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# tar xvf book.html-split.tar.bz2

Если файл сжат, tar автоматически определит подходящий формат и корректно распакует файл в набор файлов .html. Главным является index.html, и в нём находится оглавление, вводный материал и ссылки на остальные части документа.

Исчерпывающая информация содержится в разделе Руководства, который посвящён спискам рассылки, и в разделе Руководства, касающемся телеконференций.

Да, большинство сетей IRC имеют канал FreeBSD:

На FreeBSD wiki имеется хороший список каналов IRC.

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

Официальные форумы FreeBSD расположены по адресу https://forums.FreeBSD.org/.

iXsystems, Inc., дочерней компанией которой является FreeBSD Mall, предоставляет поддержку FreeBSD и программного обеспечения PC-BSD на коммерческой основе, в дополнение к разработке FreeBSD и решениям, требующим тонкой настройки.

BSD Certification Group, Inc. предоставляет сертификацию системного администрирования DragonFly BSD, FreeBSD, NetBSD и OpenBSD. Для получения дополнительной информации посетите их сайт.

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

amd64 - это термин, применяемый во FreeBSD для обозначения 64-разрядной архитектуры x86 (также известна как "x86-64" или "x64"). На большинстве современных компьютеров следует использовать amd64. Для более старых подойдёт i386. При установке системы на отличную от x86 архитектуру, выберите платформу, наиболее подходящую для оборудования.

На странице Получение FreeBSD выберите [iso] с соответствующей оборудованию архитектурой.

Можно использовать любой из:

Пользователям pc98 нужны образы дискет: floppies/boot.flp, floppies/kern1.flp, floppies/kern2.flp и floppies/mfsroot1.flp. Эти образы нужно перенести на дискеты с помощью таких утилит, как dd(1).

Полные инструкции по этой процедуре и об установке вообще можно найти в разделе Руководства, посвящённом установке FreeBSD.

Это может быть вызвано тем, что образ был загружен по FTP не в режиме binary.

В некоторых клиентских программах FTP по умолчанию используется текстовый (ascii) режим передачи, в котором любые последовательности символов "конец строки" заменяются на используемые в системе клиента. В таком случае образ загрузочного диска будет неизбежно испорчен. Проверьте контрольную сумму SHA-256 полученного файла: если он не точно такой же как на FTP-сервере, то ошибка произошла, скорее всего, в процессе передачи.

В случае использования командной строки FTP-клиента введите команду binary в командной строке FTP после подключения к серверу, но перед началом передачи файла.

Инструкции по установке FreeBSD 9.0 и более поздних версий могут быть найдены в главе Руководства, посвящённой установке FreeBSD. Также имеются инструкции по установке предыдущих версий FreeBSD.

Для работы FreeBSD необходим ПК класса 486 и выше с оперативной памятью объёмом не менее 64 Мбайт и дисковым пространством не менее 1.1 Гбайт.

Индивидуальный установочный носитель FreeBSD можно создать, запустив процедуру построения индивидуального релиза. Следуйте инструкциям в статье о подготовке релизов FreeBSD.

Да, если Windows(R) установлена первой. Загрузчик FreeBSD будет управлять процессом выбора загрузки Windows(R) или FreeBSD. Если Windows(R) устанавливается следом, то это приведёт к перезаписи загрузчика. Если такое случится, обратитесь к следующему разделу.

Способ восстановления зависит от используемого загрузчика. Меню выбора загрузки, используемое во FreeBSD, можно переустановить с помощью boot0cfg(8). Пример для восстановления меню загрузки на диске ada0:

# boot0cfg -B ada0

Неинтерактивный загрузчик MBR можно установить с помощью gpart(8):

# gpart bootcode -b /boot/mbr ada0

Более сложные ситуации, включая использование дисков GPT, рассматриваются в gpart(8).

Обычной причиной возникновения такой проблемы является неправильно сконфигурированный привод CD-ROM. Теперь зачастую ПК продаются с CD-ROM, установленным как ведомое устройство на втором контроллере IDE, но без ведущего устройства на этом контроллере. Согласно спецификации ATAPI, такая конфигурация неверна, однако Windows(R) в таком случае всё же работает, и BIOS игнорирует это при загрузке. Вот почему BIOS может видеть CD-ROM при загрузке, а FreeBSD для завершения установки - нет.

Переконфигурируйте систему так, чтобы CD-ROM оказался либо основным устройством на том IDE-контроллере, на котором он установлен, либо ведомым устройством на контроллере IDE, который имеет ведущее устройство.

В общем случае, нет. Для работы основной системы присутствие исходных текстов не требуется. Некоторые порты наподобие sysutils/lsof не будут собираться без установленных исходных текстов системы. В частности, если порт собирает модуль ядра или напрямую обращается к структурам ядра, в этом случае исходные тексты должны быть установлены.

Обычно нет. Поставляемое ядро GENERIC содержит драйвера, необходимые для типичного компьютера. Инструмент freebsd-update(8) не может использоваться для обновления FreeBSD с собственным ядром. Поэтому по возможности стоит придерживаться использования ядра GENERIC. Для компьютеров с очень небольшим объёмом ОЗУ, таких как встраиваемые системы, может потребоваться собственное небольшое ядро, содержащее только необходимые драйверы.

Во FreeBSD 9 и выше по умолчанию используется SHA512. Пароли DES остаются доступны для обратной совместимости с более старыми операционными системами, в которых используется менее защищённый формат паролей. FreeBSD также поддерживает пароли в форматах Blowfish и MD5. Управление выбором используемого формата для новых паролей осуществляется через параметр входа passwd_format в файле /etc/login.conf, принимающий значения des, blf (если они есть) или md5. Подробная информация о параметрах входа находится на странице Справочника login.conf(5).

Наибольший размер файловой системы FFS ограничен практически количеством памяти, которая требуется для работы fsck(8). fsck(8) использует 1 бит на фрагмент, и для стандартного размера фрагмента 4 Кбайт это эквивалентно использованию 32 Мбайт памяти на терабайт дискового пространства. Это означает, что на архитектурах с ограничением размера пользовательского процесса в 2 Гбайт (например, i386TM) максимальный размер файловой системы, доступный для fsck(8), составляет ~60 Тбайт.

Без ограничения на память для fsck(8) максимальный размер файловой системы составляет 2 ^ 64 (блоков) * 32 Кбайт => 16 экса * 32 Кбайт => 512 зеттабайт.

Максимальный размер файла на FFS приблизительно равен 2  петабайт со стандартным размером блока 32 Кбайт. Каждый 32 Кбайтный блок может адресовать до 4096 блоков. С использованием тройной косвенной адресации это составляет 32 Кбайт * 12 + 32 Кбайт * 4096 + 32 Кбайт * 4096^2 + 32 Кбайт * 4096^3. Увеличение размера блока до 64 Кбайт увеличит максимальный размер файла в 16 раз.

Ядро и компоненты системы не синхронизированы. Такая конфигурация не поддерживается. Обязательно используйте команды make buildworld и make buildkernel для обновления ядра.

Загрузите систему, непосредственно указав ядро на втором этапе загрузки, нажав любую клавишу до запуска загрузчика при появлении символов |.

Да, bsdconfig предоставляет замечательный интерфейс для пост-установочной настройки FreeBSD.

Наиболее вероятная причина заключается в различии между адресами физической и виртуальной памяти.

Существующее соглашение для большинства оборудования ПК заключается в использовании пространства памяти, лежащей в диапазоне между 3.5 ГБ и 4 ГБ для специальных нужд (обычно для нужд PCI). Это пространство адресов используется для доступа к PCI оборудованию. Как результат, реальная физическая память не может быть получена в данном адресном пространстве.

Какие действия выполняются с памятью в данном регионе, зависит от оборудования. К сожалению, некоторое оборудование ничего не выполняет и возможность использовать эти 500 МБ ОЗУ полностью потеряна.

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

На 32-битной версии FreeBSD кажется, что эта память потерялась, поскольку она переназначится в диапазон выше 4 ГБ, который не доступен для 32 битного ядра. В данном случае, решение заключается в сборке ядра с PAE. За дополнительной информацией обращайтесь к статье об ограничениях памяти.

На 64nbsp;битной версии FreeBSD или в случае использования ядра с включённым PAE FreeBSD корректно определит и перераспределит память, так, что она станет годной к использованию. Тем не менее, во время загрузки может показаться, что FreeBSD определяет больше памяти, чем реально имеется в системе из-за описанного перераспределения. Это нормально, и информация о доступной памяти будет скорректирована по окончанию процесса загрузки.

Ошибки выполнения, связанные с сигналом 11, происходят, когда процесс пытается обратиться к области памяти, доступ к которой ему не был дан операционной системой. Если что-то подобное происходит в случайные, казалось бы, промежутки времени, следует начать поиск причины.

Эти проблемы могут быть классифицированы следующим образом:

Вероятно, это не связано с ошибкой во FreeBSD, если проблема проявляется при компиляции программы, и при этом ошибка компилятора каждый раз разная.

Например, если запуск make buildworld завершился неудачей при попытке компиляции ls.c в ls.o и при повторном запуске компиляция снова прервалась на том же месте, то это ошибка процесса построения. Обновите исходные тексты и попробуйте снова. Если же компиляция прерывается в каком-то другом месте, то причина наиболее вероятно кроется в оборудовании.

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

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

Среди часто приводящих к этому причин:

Прочитайте раздел про Signal 11 для дальнейшего объяснения и обсуждения, как аппаратура или программное обеспечение для тестирования памяти могут пропускать сбойную память. Подробная информация по этому вопросу содержится в FAQ по проблеме SIG11.

Наконец, если ничего не помогает, то, возможно, это из-за ошибки во FreeBSD. Следуйте этим инструкциям для отправки сообщения о проблеме.

Разработчики FreeBSD интересуются такими ошибками, но им нужно больше информации, чем просто текст ошибки. Скопируйте весь текст сообщения. Затем обратитесь к разделу FAQ об аварийных завершениях работы ядра, постройте отладочное ядро и получите трассу вызовов. Это может звучать трудной задачей, зато не требует навыков программирования. Просто следуйте указаниям.

Ядро FreeBSD позволяет одновременно существовать ограниченному числу процессов. Это зависит от значения переменной sysctl(8) kern.maxusers. kern.maxusers также влияет на другие ограничения ядра, такие как буферы работы с сетью. Если система сильно загружена, поднимите kern.maxusers. Кроме максимального числа процессов это также увеличит значения других параметров, ограничивающих систему.

Для корректировки значения kern.maxusers обратитесь к разделу Ограничения файлов/процессов Руководства. В нём говорится об открытых файлах, но те же ограничения касаются процессов.

Если система загружена слабо, но в ней запущено слишком много процессов, поправьте параметр kern.maxproc, определив его значение в /boot/loader.conf. Изменение не вступит в силу до перезагрузки системы. За дополнительной информацией, касающейся настройки параметров, обращайтесь к странице Справочника loader.conf(5). Если эти процессы запущены одним и тем же пользователем, поправьте значение kern.maxprocperuid, чтобы оно было на единицу меньше, чем новое значение kern.maxproc. Оно должно быть меньше по крайней мере на единицу, потому что системная программа init(8) должна работать всегда.

На удалённой машине тип терминала может отличаться от xterm, который требуется для использования консоли FreeBSD. Либо же ядро может иметь неправильные значения ширины и высоты терминала.

Проверьте, чтобы переменная окружения TERM имела значение xterm. Если удалённая машина его не поддерживает, попробуйте vt100.

Запустите stty -a, чтобы узнать, какие размеры терминала заданы в ядре. Если значения неправильные, их можно поменять командой stty rows RR cols CC.

Либо же, если на клиентской машине установлен x11/xterm, запуск resize позволит узнать у терминала правильные размеры и применить эти значения.

Симптом: между моментом установления TCP-соединения и выдачей клиентским программным обеспечением запроса на ввод пароля (или, в случае использования telnet(1), выдачей приглашения на вход) проходит большой промежуток времени.

Проблема: скорее всего, задержка вызвана программным обеспечением на стороне сервера, которое пытается преобразовать IP-адрес клиента в имя хоста. Многие серверы, включая Telnet и SSH, поставляемые с FreeBSD, делают это для того, чтобы, кроме всего прочего, записать имя хоста в файле журнала для справки администратора.

Лечение: Если проблема возникает при подключении клиента к любому серверу, то причина в клиенте. Если проблема возникает только при чьей-либо попытке подключиться к серверу, то проблема в сервере.

Если проблема с клиентом, то единственным методом ее решения является исправление DNS, чтобы сервер смог распознать вашу машину. Если это происходит в локальной сети, то предположите, что это проблема с сервером, и продолжайте чтение. Если это происходит в сети Интернет, обратитесь к вашему провайдеру.

Если проблема с сервером в локальной сети, настройте сервер для разрешения запросов на преобразование адреса в имя хоста в диапазоне локальных адресов. Обратитесь к страницам Справочника по hosts(5) и named(8) для получения более подробной информации. Если это происходит в сети Интернет, то проблема может заключаться в некорректной работе ресолвера локального сервера. Для проверки попробуйте получить адрес другого хоста, такого как www.yahoo.com. Если это не работает, то в этом и состоит проблема.

Из-за свежей установки FreeBSD, также возможно, что информация о домене и сервере имён отсутствует в /etc/resolv.conf. Это часто будет вызывать задержку в работе SSH, так как опция UseDNS по умолчанию установлена в значение yes в /etc/ssh/sshd_config. Если именно это является причиной проблемы, то добавьте недостающую информацию в /etc/resolv.conf, либо в качестве временной меры установите UseDNS в no в файле sshd_config.

Такое сообщение об ошибке сигнализирует о том, что в системе закончились доступные файловые дескрипторы. Обратитесь к разделу kern.maxfiles главы о Настройке ограничений ядра Руководства для выяснения всех подробностей и устранения этой проблемы.

На компьютере установлено по меньшей мере два таймера, и FreeBSD выбрала не тот.

Запустите dmesg(8) и посмотрите строки, содержащие слово Timecounter. FreeBSD выбирает таймер с наибольшим значением качества.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Удостоверьтесь в этом, проверив sysctl(3)-переменную kern.timecounter.hardware.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Это может быть неработающий таймер ACPI. Самым простым решением будет отключить таймер ACPI в /boot/loader.conf:

debug.acpi.disabled="timer"

Либо же BIOS может изменить частоту TSC-может, для изменения скорости работы процессора при работе от батареек или переводя в режим пониженного электропитания, но FreeBSD не отслеживает это и в результате часы начинают спешить или отставать.

В этом примере имеется также и таймер i8254, и он может быть выбран записью его имени в sysctl(3)-переменную kern.timecounter.hardware.

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Теперь компьютер должен аккуратнее следить за временем.

Чтобы это изменение вступало в силу во время загрузки системы, добавьте в файл /etc/sysctl.conf такую строчку:

kern.timecounter.hardware=i8254

Это значит, что процесс пытается сбросить страницу памяти на диск, и попытка сделать это оканчивается неудачно в течение более 20 секунд. Это может быть вызвано испорченными блоками на диске, кабелями, подключением или другим оборудованием ввода/вывода. Если диск сам по себе испорчен, вы также увидите ошибки работы с диском в /var/log/messages и в выводе dmesg. В противном случае проверьте кабели и подключения.

Ядро FreeBSD использует несколько блокировок для арбитража доступа к соответствующим ресурсам. Когда несколько потоков в ядре пытаются захватить несколько блокировок подряд, всегда существует возможность появления мёртвой блокировки (deadlock), где два потока захватили по одной блокировке и заблокированы в ожидании освобождения другим потоком второй блокировки. Такой проблемы синхронизации можно избежать, если все потоки захватывают блокировки в одинаковом порядке.

Система диагностирования блокировок witness(4), которая по умолчанию включена во FreeBSD-CURRENT и выключена для стабильных веток и релизов, определяет возможность появления мёртвых блокировок из-за ошибок их использования, включая захват нескольких блокировок в различном порядке в разных частях ядра. Инфраструктура witness(4) пытается обнаруживать эту проблему по мере её появления и сообщает о ней на системную консоль в сообщении lock order reversal (которое также часто называют LOR).

В силу консервативности witness(4) возможны ложные срабатывания. При правильном срабатывании такое сообщение не означает, что система находится в состоянии мёртвой блокировки; его следует рассматривать как предупреждение о том, что в этом месте могла бы произойти мёртвая блокировка.

Это означает, что функция, которая может находиться в <<спящем>> состоянии была вызвана во время использования мьютекс (или другого не <<засыпающего>>) блокирования.

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

Для нахождения таких ошибок в ядро могут быть добавлены assertions, которые будут взаимодействовать с подсистемой witness(4) для генерирования предупреждения или фатальной ошибки (в зависимости от системной конфигурации) в случаях когда производится потенциально блокирующий вызов с удержанием мьютекса.

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

Дополнительная информация о синхронизации во FreeBSD находится на странице Справочника locking(9).

Эта ошибка не означает, что не найдена утилита touch(1). Ошибка наверняка появляется из-за того, что даты модификации файлов установлены в будущем. Если CMOS часы установлены на локальное время, отрегулируйте часовой механизм ядра, запустив команду adjkerntz -i в однопользовательском режиме.

Обратитесь на страницу портов, содержащую информацию о программных продуктах, перенесённых во FreeBSD. На данный момент в этом списке находится более 24,000 приложений и он ежедневно увеличивается, так что почаще туда заглядывайте или подпишитесь на Список рассылки анонсов FreeBSD, в котором публикуется информация о появлении новых приложений.

Большинство портов должно нормально работать во всех поддерживаемых версиях FreeBSD. Неработающие порты специально помечаются соответствующим образом. При выходе нового релиза FreeBSD в него в каталог ports/ включается актуальная на момент выхода Коллекция Портов.

FreeBSD умеет работать со сжатыми двоичными пакетами для упрощения установки и удаления портов. Используйте pkg(7) для управления процессом установки пакетов.

Любым из указанных способов:

Да. Для получения дополнительной информации посетите страницу http://www.FreeBSD.org/java/.

Если установленная версия FreeBSD, значительно отстаёт от -CURRENT или -STABLE, обновите Коллекцию Портов с использованием указаний в разделе Использование Коллекции Портов. Если система в актуальном состоянии, значит кто-то мог внести изменение в порт, с которым он работает в -CURRENT, но не работает в -STABLE. Пошлите сообщение об ошибке, так как Коллекция Портов должна работать как в -CURRENT, так и в ветках -STABLE.

Первым делом убедитесь, что Коллекция Портов находится в актуальном состоянии. Ошибки, которые отражаются на построении файла INDEX из актуальной копии Коллекции Портов, бросаются в глаза и поэтому практически всегда исправляются немедленно.

В редких случаях INDEX не перестраивается из-за странных комбинаций значений переменных WITH_* или WITHOUT_*, заданных в файле make.conf. Если вы думаете, что это ваш случай, прежде чем сообщать об этом в Список рассылки, посвящённый Портам FreeBSD, попытайтесь сформировать INDEX с отключенными значениями этих переменных.

С FreeBSD не поставляется инструмент обновления портов, но есть несколько инструментов, немного облегчающих этот процесс. Кроме того, для упрощения работы с портами доступны дополнительные инструменты; смотрите раздел Руководства FreeBSD Использование Коллекции Портов.

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

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

Для получения дополнительной информации обращайтесь к разделу, посвящённому обновлениям, руководства FreeBSD.

В общем случае, нет. Разработчики FreeBSD делают всё возможное для сохранения двоичной совместимости между всеми релизами в пределах одной старшей версии. Любые исключения из этого правила документируются в "Примечаниях к релизу", и там же даются советы, которых следует придерживаться.

Многим требуется, чтобы разрабатываемые скрипты для командного процессора были переносимы между многими системами. Именно поэтому в POSIX(R) очень подробно описан командный процессор и набор утилит. Большинство скриптов пишутся на языке процессора Bourne shell (sh(1)), к тому же некоторые важные программные вызовы (make(1), system(3), popen(3) и их аналоги на языках скриптов высокого уровня, таких как Perl или Tcl) предполагают для интерпретации команд использование именно Bourne shell. Так как Bourne shell используется столь широко и часто, то очень важно, чтобы он стартовал очень быстро, его поведение было строго регламентировано и при этом потребности в оперативной памяти были малы.

В имеющейся реализации мы приложили максимум усилий для воплощения в жизнь всех этих требований одновременно. Для того, чтобы сохранить /bin/sh небольшим по размеру, мы не включили многие из обычных возможностей, которые имеются в других командных процессорах. Для этого имеются в наличии командные процессоры, обладающие гораздо большими возможностями, такие как bash, scsh, tcsh(1) и zsh. Сравните использование памяти этими оболочками, посмотрев в колонки <<VSZ>> и <<RSS>> вывода команды ps -u.

Для создания аудио-CD из MIDI-файлов сначала установите из портов программу audio/timidity++, затем установите набор патчей GUS от Эрика Уэлша (Eric A. Welsh), доступный по адресу http://alleg.sourceforge.net/digmid.html. После корректной установки TiMidity++ MIDI-файлы могут быть преобразованы в WAV-файлы следующей командой:

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

WAV-файлы затем могут быть преобразованы в другие форматы или записаны как аудио-CD, что описано в Руководстве FreeBSD.

Вовсе нет! Обратитесь к соответствующему разделу Руководства, который посвящён этому вопросу.

Конфигурация ядра GENERIC, которая содержится в дистрибутиве FreeBSD, компилируется в отладочном режиме. В таком режиме ядра содержат много символьной информации в разных файлах, которая используется для отладки и сильно увеличивает размер /boot/kernel/. Заметьте, что уменьшения производительности при использовании отладочного ядра нет или оно незначительно, однако отладочное ядро полезно иметь под рукой на случай аварийного завершения работы системы.

Однако при нехватке дискового пространства существует несколько вариантов уменьшения размера >/boot/kernel/.

Чтобы не устанавливать файлы с символьной информацией, убедитесь в наличии следующей строки в /etc/src.conf:

WITHOUT_KERNEL_SYMBOLS=yes

Для получения дополнительной информации смотрите страницу Справочника src.conf(5).

Если вы не хотите компилировать отладочное ядро, убедитесь в выполнении следующих условий:

В любой из вышеописанных ситуаций ядро будет построено с отладочным режимом.

Чтобы скомпилировать и установить только нужные модули, укажите их в /etc/make.conf:

MODULES_OVERRIDE= accf_http ipfw

Замените accf_httpd ipfw на нужный список модулей. Это уменьшит размер каталога с ядром, а также время сборки. Для получения дополнительной информации почитайте /usr/share/examples/etc/make.conf.

Для дальнейшего уменьшения размера также можно удалить ненужные устройства из ядра. Для получения дополнительной информации смотрите Вопрос: 7.1.

Для вступления любого из этих действий в силу следуйте указаниям по сборке и установке нового ядра.

Большинство ядер (/boot/kernel/kernel), как правило, занимают от 12 до 16 Мбайт.

Есть несколько причин, приводящих к возникновению этой проблемы:

Название используемого планировщика доступно напрямую в виде значения sysctl-параметра kern.sched.name:

% sysctl kern.sched.name
kern.sched.name: ULE

kern.sched.quantum определяет максимальное количество тактов, которое процесс может выполняться, не будучи прерванным.

Обратитесь к разделу Добавление дисков Руководства FreeBSD.

Самый лучший способ заключается в переустановке операционной системы на новый диск с последующим переносом пользовательских данных. Это настоятельно рекомендуется при отслеживании ветки -STABLE в течение более одного релиза или при обновлении релиза вместо установки нового. Установите booteasy на оба диска с помощью boot0cfg(8) и выполняйте загрузку с любого из них, пока не будете довольны новой конфигурацией. Пропустите следующий абзац, чтобы перейти к вопросу переноса данных после этой операции.

Либо разбейте на разделы и разметьте новый диск с помощью sade(8) или gpart(8). Если диски отформатированы в MBR, то booteasy можно установить на оба диска с помощью boot0cfg(8) для того, чтобы иметь возможность выполнять загрузку как старой, так и новой системы после выполнения копирования.

После подготовки диска данные нельзя просто так взять и перенести. Используйте для этого инструменты, которые учитывают файлы устройств и системные флаги, например, dump(8). И хотя рекомендуется выполнять перенос данных в однопользовательском режиме, это не является обязательным условием.

Если на дисках стоит UFS, никогда не используйте ничего, кроме dump(8) и restore(8) для переноса корневой файловой системы. Эти команды также следует использовать при переносе отдельного раздела на другой пустой раздел. Последовательность шагов при использовании dump для переноса данных с раздела UFS на новый раздел:

Например, чтобы перенести корневую файловую систему на устройство /dev/ada1s1a с использованием каталога /mnt в качестве временной точки монтирования, наберите:

# newfs /dev/ad1as1a
# mount /dev/ad1as1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

Переразбиение разделов с использованием dump требует несколько больше усилий. Для объединения раздела типа /var с его вышестоящим разделом, создайте новый раздел, достаточно большой для размещения их обоих, переместите вышестоящий раздел так, как это описано выше, а затем переместите нижестоящий раздел в пустой каталог, созданный при первом перемещении:

# newfs /dev/ada1s1a
# mount /dev/ad1as1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Для отделения каталога от вышестоящего, скажем, для размещения /var в собственном разделе, которого не было, создайте оба раздела, затем смонтируйте нижестоящий раздел в подходящий каталог во временную точку монтирования, а затем переместите старый единый раздел:

# newfs /dev/ada1s1a
# newfs /dev/ada1s1d
# mount /dev/ada1s1a /mnt
# mkdir /mnt/var
# mount /dev/ada1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

Для перемещения пользовательских данных также имеются программы cpio(1) и pax(1). Известно, что они теряют информацию о флагах файлов, так что используйте их с осторожностью.

Краткий ответ: обычно Soft Updates можно использовать без опаски на всех разделах.

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

При использовании Soft Updates ядро может задерживать до тридцати секунд запись изменений на физический диск. При удалении большого файла он остается на диске, пока ядро не выполнит фактическое удаление. Это может привести к очень простой гонке. Предположим, удаляется один большой файл и тут же создаётся другой большой файл. Первый файл на самом деле ещё не удалён с диска, поэтому для второго файла на диске может не хватить места. Это приведёт к ошибке о том, что на разделе нет достаточного пространства, несмотря на то, что только что освободилось много места. Через пару секунд создание файла сработает, как и ожидалось.

Если система может аварийно остановиться после того, как ядро примет набор данных для записи на диск, но перед тем, как данные реально запишутся, то данные могут потеряться. Такой риск чрезвычайно мал, но в целом управляем.

Эти проблемы влияют на все разделы, использующие Soft Updates. Итак, что это означает для корневого раздела?

Жизненно важная информация на корневом разделе меняется очень редко. Если в системе произойдет сбой в период тридцатисекундного окна после выполнения такого изменения, возможно, что данные окажутся потерянными. Этот риск незначителен для большинства применений, но его нужно учитывать. Если система не может принять такой риск, не используйте Soft Updates с корневой файловой системой!

/ традиционно является одним из самых маленьких разделов. Если каталог /tmp размещён в / и у вас заполнен /tmp, то могут периодически возникать проблемы с дисковым пространством. Создание символической ссылки /tmp, указывающей на /var/tmp решит эту проблему.

В заключение, dump(8) не работает в режиме реального времени (-L) с файловой системой, для которой включены журналируемые Soft Updates (SU+J).

FreeBSD поддерживает ряд других файловых систем.

FreeBSD включает сетевую файловую систему NFS. В Коллекции портов FreeBSD имеется несколько приложений FUSE для поддержки многих других файловых систем.

Вторичные разделы DOS находятся после всех первичных разделов. Например, если <<E>> является вторым разделом DOS на втором диске SCSI, то здесь будет файл устройства для пятого <<слайса>> в каталоге /dev. Чтобы смонтировать:

# mount -t msdosfs /dev/da1s5 /dos/e

Да, gbde(8) и geli(8). Смотрите раздел Шифрование дисковых разделов Руководства FreeBSD.

Для загрузки FreeBSD с использованием GRUB добавьте следующие строки в /boot/grub/menu.lst или /boot/grub/grub.conf, в зависимости от используемого дистрибутива Linux(R).

title FreeBSD 9.1
root (hd0,a)
kernel /boot/loader

Где hd0,a указывает на корневой раздел на первом диске. Чтобы указать номер слайса, напишите что-то вроде (hd0,2,a). По умолчанию, если номер слайса не указан, GRUB ищет первый слайс c разделом a.

Установите LILO в начало загрузочного раздела Linux(R), а не в Master Boot Record. После этого LILO можно будет запустить LILO из BootEasy.

Это рекомендуется делать при одновременном использовании Windows(R) и Linux(R), чтобы упростить восстановление работоспособности Linux(R) в случае переустановки Windows(R).

Этого нельзя сделать со стандартным загрузчиком, не переписав его. В категории sysutils Коллекции Портов есть ряд других менеджеров загрузки.

Если у вас уже есть файловая система на устройстве, то используйте такую команду:

# mount -t msdosfs /dev/da0s1 /mnt

Если это устройство будет использоваться только на системах FreeBSD, то разбейте его на разделы UFS или ZFS. Это обеспечит поддержку длинных имён файлов, увеличение производительности и надёжность. Если устройство будет использоваться с другими операционными системами, то лучше сделать более совместимый выбор, например, msdosfs.

# dd if=/dev/zero of=/dev/da0 count=2
# gpart create -s GPT /dev/da0
# gpart add -t freebsd-ufs /dev/da0

Наконец, остаётся создать новую файловую систему:

# newfs /dev/da0p1

и смонтировать её:

# mount /dev/da0s1 /mnt

Хорошо ещё добавить строку в файл /etc/fstab (прочтите справку по fstab(5)), чтобы в будущем можно было просто давать команду mount /mnt:

/dev/da0p1 /mnt ufs rw,noauto 0 0

Необходимо указать тип монтируемого устройства. Это описано в в разделе Руководства Использование CD с данными.

Обычно это означает, что в приводе нет компакт-диска либо устройство не обнаружено на шине. Обратитесь к разделу Использование CD с данными в Руководстве, где подробно обсуждается этот вопрос.

Скорее всего, на компакт-диске для хранения информации о файлах и каталогах используется расширение <<Joliet>>. Это описано в разделе Руководства об использовании CD с данными.

Это означает, что на CD был записан непосредственно необработанный файл без создания файловой системы ISO 9660. Прочтите раздел Руководства о записи данных непосредственно на компакт-диски.

Это описано в разделе Руководства о копировании CD с данными. Более полную информацию о работе с компакт-дисками можно найти в разделе о создании компакт-дисков в главе Руководства об устройствах хранения данных.

Попытка смонтировать аудио CD приведёт к сообщению об ошибке вида: cd9660: /dev/acd0c: Invalid argument. Причина этого заключается в том, что команда mount работает только с файловыми системами. На аудио CD файловых систем нет; они содержат только данные. Используйте вместо этого программу, которая умеет читать аудио CD, например, порт audio/xmcd.

По умолчанию mount(8) будет пытаться смонтировать последнюю дорожку (сеанс) CD с данными. Для загрузки более раннего сеанса используйте параметр командной строки -s. За конкретными примерами обращайтесь к странице Справочника mount_cd9660(8).

Как пользователь root, установите системную переменную vfs.usermount в значение 1.

# sysctl vfs.usermount=1

Чтобы это срабатывало во время загрузки системы, добавьте строчку vfs.usermount=1 в файл /etc/sysctl.conf.

Пользователи могут монтировать только те устройства, к которым у них имеется доступ на чтение. Чтобы разрешить пользователям монтировать устройство, должны быть заданы разрешения в /etc/devfs.conf.

Например, чтобы разрешить пользователям монтировать первое устройство USB, добавьте такую строчку:

# Allow all users to mount a USB drive.
	    own       /dev/da0       root:operator
	    perm      /dev/da0       0666

Теперь все пользователи могут монтировать устройства с правами доступа на чтение в собственные каталоги:

% mkdir ~/my-mount-point
% mount -t msdosfs /dev/da0 ~/my-mount-point

Размонтирование устройства осуществляется просто:

% umount ~/my-mount-point

Использование vfs.usermount, однако, имеет некоторые негативные стороны, связанные с вопросами безопасности. Более правильным способом работы с носителями в формате MS-DOS(R) является использование пакета emulators/mtools из Коллекции Портов.

Это связано с тем, как эти команды на самом деле работают. du проходит по дереву каталогов, замеряя, насколько большой объем занимает каждый файл, и выдает общий объем. df просто запрашивает файловую систему об оставшемся объеме. Это выглядит как одно и то же, однако файл без записи в каталоге затронет df, но не повлияет на du.

Когда программа использует файл и этот файл удаляется, то на самом деле он не удаляется из файловой системы, пока программа не прекратит его использовать. Однако файл тут же удаляется из списка каталога. Представим себе файл достаточно большого размера, чтобы его присутствие влияло на вывод du и df. Если файл удаляется в процессе работы с ним команды more, команда more не сообщает сразу же, что не может просматривать файл. Запись о файле просто удалена из каталога, так что другие программы или пользователи не смогут к нему обратиться. Тем не менее, du покажет, что файл исчез, поскольку она просматривает дерево каталогов, а файла там нет. df показывает, что файл всё ещё здесь, так как файловая система знает, что more всё ещё использует это пространство. Как только закончится работа с more, команды du и df придут в соответствие.

Такая ситуация часта на Web-серверах. Многие устанавливают Web-сервер на FreeBSD и забывают обновлять файлы протоколов. Журнал доступа заполняет /var. Новый администратор удаляет файл, но система все еще сообщает о том, что раздел заполнен. Остановка и перезапуск программы Web-сервера освободит файл, позволяя системе освободить дисковое пространство. Для предотвращения этого настройте newsyslog(8).

Заметьте, что подсистема отложенных обновлений (Soft Updates) может задерживать освобождение дискового пространства, и может потребоваться до 30 секунд, чтобы изменения стали заметны.

В этом разделе Руководства описывается, как это сделать.

Производители дисков считают гигабайт равным миллиарду байт, а FreeBSD приравнивает его к 1073741824 байт. Это объясняет, почему, к примеру, в сообщениях при загрузке FreeBSD указывается, что ёмкость диска, объём которого должен быть равным 80 Гбайт, составляет 76319 Мбайт.

Заметьте также, что FreeBSD будет (по умолчанию) резервировать 8% ёмкости диска.

Часть каждого раздела UFS (по умолчанию 8%) зарезервировано для использования операционной системой и пользователем root. Утилита df(1) не учитывает это при подсчёте значения в колонке Capacity, так что оно может превышать 100%. Обратите внимание, что колонка Blocks всегда больше, чем сумма значений в колонках Used и Avail, обычно на 8%.

Для получения более подробной информации обратитесь к описанию опции -m в справке по tunefs(8).

FreeBSD выполняет короткую проверку памяти на раннем этапе загрузки. Обычно эта проверка занимает всего несколько секунд, но если система имеет много десятков или сотен Гбайт памяти, это можно занять до нескольких минут. Эту проверку можно отключить, установив hw.memtest.tests в значение 0 в /boot/loader.conf.

Для получения дополнительной информации смотрите страницу Справочника loader.conf(5).

Для комфортного использования требуется 4 Гбайт ОЗУ, но конкретная нагрузка может сильно различаться.

ZIL ((ZFS intent log) - это журнал записи, используемый для фиксации операций записи. Обычно операции собираются в группу транзакций и при заполнении группы пишутся на диск (<<Transaction Group Commit>>). Однако системные вызовы типа fsync(2) требуют фиксацию записи данных на устройстве перед возвратом управления. ZIL нужен для подтверждения такой записи, но когда данные ещё не находятся на диске. Группа транзакций помечается временной меткой. В случае системного сбоя ищется последняя неповреждённая метка и из ZIL извлекаются недостающие данные.

По умолчанию ZFS хранит ZIL в пуле со всеми данными. Если приложение имеет большой процент записи, вынос ZIL на отдельное устройство с очень быстрой синхронной последовательной записью может улучшить общую производительность. В остальных случаях SSD вряд ли сможет что-то сильно улучшить.

L2ARC - это кеш на чтение, хранимый на быстром устройстве, таком как SSD. Этот кеш не сохраняется между перезагрузками. Следует заметить, что ОЗУ выступает как кеш первого уровня, а L2ARC задействуется только при нехватке ОЗУ.

Для L2ARC нужно пространство в ARC для его индексации. Таким образом, рабочий набор, который идеально помещается в ARC, не будет помещаться при использовании L2ARC, потому что часть ARC будет отведена под индекс L2ARC с вытеснением части рабочего набора в L2ARC, более медленный, чем ОЗУ.

В общем случае нет.

Дедупликация занимает значительный объём ОЗУ и может увеличить задержки операций ввода/вывода. Если данные не являются сильно дублированными (образы виртуальных машин или пользовательские бекапы), то, возможно, дедупликация даст больше вреда. Другое соображение касается невозможности отменить статус дедупликации. Если данные записаны при включённой дедупликации, её выключение не приведёт к обратной репликации объединённых блоков до момента следующей перезаписи.

Дедупликация также может приводить к некоторым неожиданным ситуациям. В частности, удаление файлов может сильно замедлиться.

Такое может произойти при 100% заполненности пула. ZFS требуется свободное место на диске для записи метаданных транзакций. Для восстановления работоспособного состояния пула обрежьте файл перед его удалением.

% truncate -s 0 unimportant-file

Обрезание файла работает по той причине, что новая транзакция при этом не запускается; вместо этого создаются новые свободные блоки.

Поддержка ZFS TRIM была добавлена во FreeBSD 10-CURRENT в ревизии r240868 и стала доступна в ветках -STABLE в r252162 и r251419.

ZFS TRIM включена по умолчанию и может быть отключена посредством добавления такой строки в /etc/sysctl.conf:

vfs.zfs.trim_disable=1

Основным конфигурационным файлом является /etc/defaults/rc.conf, который описан в rc.conf(5)). Этот файл подключают системные скрипты запуска, такие как /etc/rc и /etc/rc.d, которые описаны в rc(8). Не редактируйте этот файл! Вместо изменения параметра в /etc/defaults/rc.conf скопируйте эту строку в /etc/rc.conf и поменяйте значение там.

Пример запуска named(8), поставляемого с системой сервера DNS:

# echo 'named_enable="YES"' >> /etc/rc.conf

Чтобы запустить местные сервисы, поместите скрипты в каталог /usr/local/etc/rc.d. У этих скриптов должен быть выставлен бит выполнимости, по умолчанию используются права доступа 555.

Используйте команду adduser(8) или pw(8) в случае выполнения более сложных операций.

Чтобы удалить пользователя, используйте команду rmuser(8) или, если это будет необходимо, pw(8).

Обычно это случается при редактировании системного файла crontab.

Это неправильный подход, потому что системный crontab имеет формат, отличный от пользовательских crontab. Системный crontab имеет дополнительное поле, указывающее, под каким пользователем запускать команду. cron(8) полагает, что имя пользователя является первым словом в команде на выполнение. Поскольку такой команды не существует, отображается это сообщение об ошибке.

Чтобы удалить лишний неправильный crontab:

# crontab -r

Это особенность работы системы защиты. Для того, чтобы сменить пользовательский идентификатор с помощью su на пользователя root или любого другого с привилегиями суперпользователя, учётная запись должна являться членом группы wheel. Если бы этого не было, то любой, имеющий доступ к системе и узнавший пароль пользователя root, смог бы получить в системе уровень доступа суперпользователя.

Чтобы разрешить кому-либо менять привилегии на root, включите его в группу wheel с помощью pw.

# pw groupmod wheel -m lisa

В примере выше пользователь lisa будет добавлен в группу wheel.

Перезапустите систему, используя в приглашении загрузчика команду boot -s для входа в однопользовательский режим. При получении приглашения на ввод полного пути до командного процессора нажмите Enter, а затем выполните команду mount -urw / для повторного монтирования корневой файловой системы в режиме чтения/записи. Вам может также потребоваться выполнить команду mount -a -t ufs для монтирования файловой системы, в которой расположен ваш любимый текстовый редактор. Если редактор расположен на сетевой файловой системе, либо выполните сетевые настройки вручную до монтирования сетевой файловой системы, либо воспользоваться редактором, находящимся в локальной файловой системе, таким, как ed(1).

Чтобы использовать полноэкранный редактор, такой как vi(1) или emacs(1), выполните команду export TERM=xterm во FreeBSD 9.0+ или export TERM=cons25 во FreeBSD 8.X, чтобы такие редакторы смогли корректно взять данные из базы данных termcap(5).

После выполнения этих шагов отредактируйте файл /etc/rc.conf для исправления ошибки. Сообщение об ошибке, выводимое сразу же после сообщений при загрузке ядра, должно указать на номер строки в файле, которая содержит ошибку.

Обратитесь к соответствующему разделу Руководства, посвящённому печати, за советами по разрешению проблем.

Обратитесь к разделу Руководства, посвящённому использованию локализации, а именно к части, описывающей настройку консоли.

Да, во FreeBSD в ядро GENERIC включена поддержка IPC в стиле System V, в том числе совместно используемой памяти, сообщений и семафоров. В вашем собственном ядре поддержка может быть включена посредством загрузки модулей ядра sysvshm.ko, sysvsem.ko и sysvmsg.ko или добавлением в конфигурационный файл ядра следующих строк:

options    SYSVSHM	  # enable shared memory
options    SYSVSEM	  # enable for semaphores
options    SYSVMSG	  # enable for messaging

Перекомпилируйте и переустановите ядро.

Сервер Sendmail является программным обеспечением для работы почтового сервера во FreeBSD, используемым по умолчанию, но его можно заменить другим MTA, установленным из Коллекции Портов. В дереве портов имеется mail/exim, mail/postfix и mail/qmail. Проверьте архивы списков рассылки на предмет обсуждения достоинств и недостатков имеющихся MTA.

Без паники! Перезапустите систему, наберите boot -s в приглашении Boot: для входа в однопользовательский режим. На вопрос об используемой оболочке нажмите Enter для получения приглашения #. Введите mount -urw /, чтобы перемонтировать корневую файловую систему в режиме чтения/записи, после чего выполните команду mount -a для монтирования всех файловых систем. Запустите команду passwd root, чтобы сменить пароль пользователя root, а затем exit(1) для продолжения процесса загрузки.

При использовании стандартного драйвера консоли syscons(4) перегенерируйте и установите новое ядро с таким параметром в конфигурационном файле:

options SC_DISABLE_REBOOT

Этого также можно достичь установкой следующего sysctl(8), что не требует перезагрузки или пересборки ядра:

# sysctl hw.syscons.kbd_reboot=0

Воспользуйтесь следующей командой perl(1):

% perl -i.bak -npe 's/\r\n/\n/g' file(s)

где file(s) - это один или несколько файлов для обработки. Преобразование делается в том же самом файле, оригинальные файлы сохраняются с расширением .bak.

Либо используйте tr(1):

% tr -d '\r' < dos-text-file > unix-file

где dos-text-file - это имя файла, содержащего текст DOS, а в файл unix-file будет помещён уже преобразованный текст. Этот способ может работать гораздо быстрее, чем при использовании perl.

Еще один способ отформатировать тестовые файлы DOS состоит в использовании converters/dosunix из Коллекции Портов. Для получения дополнительной информации ознакомьтесь с документацией порта.

Перейдите в однопользовательский режим, а затем возвратитесь обратно в многопользовательский.

# shutdown now
# return
# exit

Краткий ответ: это же просто название. RC означает <<Release Candidate>>. Это значит, что вскоре произойдет выход релиза. Во FreeBSD появление -PRERELEASE, как правило, равнозначно прекращению внесения изменений в код системы перед появлением релиза. (Для некоторых релизом метка -BETA использовалась точно так же, как и -PRERELEASE.)

Подробный ответ: во FreeBSD релизы выпускаются из одного из двух мест. Крупные релизы, точка-ноль, такие, как 9.0-RELEASE и 10.0-RELEASE, ответвляются от основного потока разработки, более известного как -CURRENT. Мелкие релизы, такие, как 6.3-RELEASE или 5.2-RELEASE, являлись снэпшотами активной ветки -STABLE. Начиная с 4.3-RELEASE, каждый релиз также имеет свою ветвь, которой могут следовать те, кому необходим сверхконсервативный метод обновления (как правило, внесение только тех исправлений, которые касаются вопросов обеспечения безопасности).

Когда делается релиз, то ветвь, из которой он выпускается, подвергается некоторой подготовке. Частью этого процесса является замораживание кода. Когда инициируется замораживание кода, то имя ветки изменяется для того, чтобы отразить факт близости релиза. Например, если ветка называлась 6.2-STABLE, то её имя будет изменено на 6.3-PRERELEASE, чтобы обозначить момент прекращения внесения изменений в код системы и период дополнительного тестирования перед выходом релиза. В это время исправления ошибок могут быть внесены в код системы для того, чтобы быть включенными в релиз. Когда исходный код подготовлен к выпуску релиза, имя будет изменено на 6.3-RC для обозначения того, что релиз будет сделан, скорее всего, именно из этого кода. Когда код находится на этапе RC, в нём могут исправляться только самые критичные ошибки. Как только релиз (в нашем примере 6.3-RELEASE) и ветка релиза будут созданы, ветвь будет переименована в 6.3-STABLE.

Для получения дополнительной информации о номерах версий и различных ветках Subversion обратитесь к статье о выпуске релизов.

Краткий ответ: Режим безопасности имеет значение больше нуля. Для установки ядра перезагрузите машину и войдите в однопользовательский режим.

Подробный ответ: FreeBSD запрещает менять системные флаги при работе на уровнях безопасности, превышающих 0. Чтобы проверить текущий уровень безопасности:

# sysctl kern.securelevel

Уровень безопасности нельзя понизить в многопользовательском режиме, поэтому для установки ядра загрузитесь в однопользовательский режим, или измените уровень безопасности в /etc/rc.conf, а затем выполните перезагрузку. Обратитесь к странице Справочника по init(8) за подробной информацией о securelevel и посмотрите /etc/defaults/rc.conf и справочную страницу по rc.conf(5) для выяснения подробностей о файле rc.conf.

Краткий ответ: Система работает на уровне безопасности со значением выше 1. Для смены даты перезагрузите машину и войдите в однопользовательский режим.

Подробный ответ: FreeBSD запрещает менять системное время больше чем на одну секунду на уровне безопасности выше 1. Чтобы определить уровень безопасности:

# sysctl kern.securelevel

Уровень безопасности нельзя понизить в многопользовательском режиме. Для изменения даты перезагрузите систему в однопользовательский режим, либо измените уровень безопасности в /etc/rc.conf, а затем выполните перезагрузку. Обратитесь к странице Справочника по init(8) за подробной информацией о securelevel и посмотрите /etc/defaults/rc.conf и справочную страницу по rc.conf(5) для выяснения подробностей о файле rc.conf.

Нет, там нет ошибок и он не использует 256 Мбайт памяти. Для удобства rpc.statd отображает неприлично большой кусок памяти в своё адресное пространство. Здесь нет ничего неправильного с технической точки зрения, это просто сбивает с толку программы вроде top(1) и ps(1)

rpc.statd(8) отображает свой статусный файл (находящийся на /var) в свое адресное пространство. Для того, чтобы постоянно не беспокоиться о будущих переотражениях, когда файл вырастет в размерах, он просто отображает его с огромным размером заранее. Это просто заметить в исходных текстах, где как вы можете увидеть параметр длина к функции mmap(2) имеет значение 0x10000000, или одна шестнадцатая адресного пространства для IA32, то есть 256 Мбайт.

Система работает с уровнем защиты выше нуля. Понизьте уровень защиты и попробуйте еще раз. Для получения более подробной информации обратитесь к разделу FAQ об уровне защиты и справочной странице init(8).

vnlru сбрасывает и освобождает vnode, когда система достигает ограничения по параметру kern.maxvnodes. Этот поток ядра в основном работает вхолостую и активируется только при наличии огромного объема ОЗУ и обращении к десяткам тысяч файлов небольшого размера.

Страницы чаще всего записываются на диск (типа синхронизации VM), когда они находятся в неактивном состоянии, однако страницы в активном состоянии также могут сбрасываться. Это зависит от наличия и возможности отслеживания со стороны ЦП бита 'модифицированности', и в некоторых ситуациях это может быть лучше для блока синхронизируемых страниц VM, вне зависимости от их активности. В большинстве встречающихся ситуаций лучше всего представлять неактивную очередь как очередь сравнительно неиспользуемых страниц, которые могут быть, а могут и не быть в процессе записи на диск. Кэшируемые страницы уже синхронизированы, не отображаются, но доступны для непосредственного использования процессом со своей старой или новой привязкой. Свободные страницы доступны на уровне прерывания, однако кэшируемые или свободные страницы могут использоваться в процессе повторно. Кэшируемые страницы недостаточно заблокированы для того, чтобы быть доступными на уровне прерывания.

Есть ещё некоторые другие флаги (например, флаг занятости или счётчик занятости), которые могут изменить некоторые описанные правила.

Есть несколько понятий <<свободной памяти>>. В одном случае это объём памяти, непосредственно доступной в данный момент без страничной выгрузки чего-либо. Этот объём равен примерно размеру очереди кэша + размер очереди на высвобождение (с учётом допустимых отклонений, зависящих от настроек системы). В другом случае <<свободная память>> обозначает общий объём пространства VM. Он может сложно вычисляться, но зависит от объёма раздела подкачки и памяти. Другие определения <<свободной памяти>> также возможны, но они достаточно бесполезны, ведь в любом случае важно сохранять низкий уровень подкачки и избегать исчерпания раздела подкачки.

/var/empty представляет собой каталог, который используется в программе sshd(8) при выполнении разделения полномочий. Каталог /var/empty пуст, его владельцем является root, и на нём установлен флаг schg. Этот каталог не должен удаляться.

Чтобы посмотреть, что будет делать newsyslog(8), используйте следующую команду:

% newsyslog -nrvv

Используйте tzsetup(8).

X Window System (обычно X11) является наиболее общедоступной оконной системой, которая может работать на UNIX(R) и UNIX(R)-подобных системах, в том числе и во FreeBSD. Разработкой стандартов на используемый X-протокол занимается организация The X.Org Foundation, с текущей эталонной реализацией version 11 release 7.7, поэтому название часто сокращается до X11.

Для разных архитектур и операционных систем существует множество реализаций этой системы. Реализацию кода для серверной части называют X-сервером.

Для установки Xorg выполните одно из действий:

Используйте мета-порт x11/xorg, который выполняет построение и установку всех компонентов Xorg.

Используйте x11/xorg-minimal, который выполняет построение и установку только необходимых компонентов Xorg.

Установите Xorg из пакетов FreeBSD.

# pkg install xorg

После установки Xorg следуйте указаниям в разделе Конфигурация X11 Руководства FreeBSD.

Вероятно, в системе установлен повышенный уровень безопасности (securelevel). При повышенном уровне защиты систему X запустить невозможно, потому что X требуются права на операции записи в устройство io(4). Дополнительная информация находится на странице Справочника init(8).

Существует два решения проблемы: установить значение securelevel обратно в ноль или запускать xdm(1) (или любой другой оконный менеджер) во время загрузки, до того как повышается значение securelevel.

Обратитесь к Вопрос: 11.10 для получения более полной информации о запуске xdm(1) во время загрузки.

При использовании стандартного драйвера консоли syscons(4) во FreeBSD можно включить поддержку указателя мыши во всех виртуальных экранах. Во избежание конфликтов с X, драйвер syscons(4) поддерживает виртуальное устройство /dev/sysmouse. Все события от реального устройства мыши пишутся в устройство sysmouse(4) через moused(8). Чтобы использовать мышь на одной и более виртуальных консолях, и при этом продолжать использовать X, посмотрите Вопрос: 4.4.1 и настройте moused(8).

Затем отредактируйте /etc/X11/xorg.conf, чтобы в нём были следующие строки:

Section "InputDevice"
   Option	  "Protocol" "SysMouse"
   Option	  "Device" "/dev/sysmouse"
.....

Начиная с версии Xorg 7.4 раздел InputDevice в файле xorg.conf игнорируется, и вместо него используется механизм автоматически определяемых устройств. Чтобы восстановить прежнее поведение, добавьте в раздел ServerLayout или ServerFlags такую строку:

Option "AutoAddDevices" "false"

Некоторые предпочитают использовать в X устройство /dev/mouse. Чтобы оно работало, файл устройства /dev/mouse должен являться ссылкой на /dev/sysmouse (посмотрите справку по sysmouse(4)). Это можно сделать, добавив следующую строку в /etc/devfs.conf (посмотрите справку по devfs.conf(5)):

link    sysmouse    mouse

Ссылка может быть создана путем перезапуска devfs(5) с использованием следующей команды (из под пользователя root):

# service devfs restart

Да, если X настроена для использования 5-кнопочной мыши. Для этого добавьте строчки Buttons 5 и ZAxisMapping 4 5 в раздел <<InputDevice>> файла /etc/X11/xorg.conf как показано в этом примере:

Section "InputDevice"
   Identifier      "Mouse1"
   Driver	  "mouse"
   Option	  "Protocol" "auto"
   Option	  "Device" "/dev/sysmouse"
   Option	  "Buttons" "5"
   Option	  "ZAxisMapping" "4 5"
EndSection

Для использования мыши в Emacs также добавьте в ~/.emacs следующие строки:

;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

Для его работы понадобится настроить некоторые вещи.

Чтобы использовать драйвер synaptics из Xorg, для начала удалите строку moused_enable из rc.conf.

Для включения synaptics добавьте следующую строку в /boot/loader.conf:

hw.psm.synaptics_support="1"

Добавьте следующее в /etc/X11/xorg.conf:

Section "InputDevice"
Identifier  "Touchpad0"
Driver      "synaptics"
Option      "Protocol" "psm"
Option      "Device" "/dev/psm0"
EndSection

И не забыть добавить следующее в раздел <<ServerLayout>>:

InputDevice    "Touchpad0" "SendCoreEvents"

Из соображений обеспечения информационной безопасности открывать удалённые окна на машине по умолчанию запрещено.

Для включения этой возможности запустите X с аргументом -listen_tcp:

% startx -listen_tcp

Виртуальные консоли предоставляют несколько одновременных сеансов работы с той же самой машиной без установки какой бы то ни было сети или запуска X.

При запуске системы после вывода сообщений этапа загрузки на консоль выдаётся приглашение для входа в систему. Введите своё имя и пароль, чтобы начать работу на первой виртуальной консоли.

Чтобы запустить ещё один сеанс, скажем, чтобы заглянуть в документацию по программе или для чтения электронной почты во время ожидания завершения передачи данных по FTP, нажмите F2, удерживая Alt. Это отобразит приглашение на второй виртуальной консоли. Чтобы вернуться к первоначальному сеансу, нажмите Alt+F1.

По умолчанию во FreeBSD задействованы восемь виртуальных консолей, а комбинации клавиш Alt+F1, Alt+F2, Alt+F3 и далее служат для переключения между ними.

Чтобы увеличить количество виртуальных консолей, отредактируйте /etc/ttys (смотрите страницу Справочника ttys(5)), добавив туда записи для терминалов с именами от ttyv8 до ttyvc после комментария про <<Virtual terminals>>:

# Edit the existing entry for ttyv8 in /etc/ttys and change
# "off" to "on".
ttyv8   "/usr/libexec/getty Pc"	 xterm  on secure
ttyv9   "/usr/libexec/getty Pc"	 xterm  on secure
ttyva   "/usr/libexec/getty Pc"	 xterm  on secure
ttyvb   "/usr/libexec/getty Pc"	 xterm  on secure

Чем больше виртуальных терминалов, тем больше ресурсов используется. Это может привести к проблемам на системах с 8 Мбайт ОЗУ или меньше. Подумайте о смене статуса консолей с secure на insecure.

Например, чтобы запустить X и 11 виртуальных консолей, нужно настроить двенадцатый виртуальный терминал:

ttyvb   "/usr/libexec/getty Pc"	 xterm  off secure

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

Используйте комбинацию клавиш Ctrl+Alt+Fn для переключения обратно в виртуальную консоль. Нажмите Ctrl+Alt+F1, чтобы вернуться на первую виртуальную консоль.

После того, как вы оказались в текстовой консоли, используйте комбинации Alt+Fn для переключения между ними.

Чтобы вернуться в сеанс работы X, переключитесь в виртуальную консоль, на которой запущена X Window. Если X был запущен из командной строки с использованием команды startx, то сеанс работы X будет привязан к следующей неиспользуемой виртуальной консоли, а не к той текстовой консоли, с которой он был запущен. В случае восьми активных виртуальных терминалов X будет работать на девятом, поэтому используйте комбинацию Alt+F9.

Есть две философские школы, проповедующие различные методы запуска xdm(1). Последователи одного течения запускают xdm из /etc/ttys (посмотрите ttys(5)), используя приводимый пример, тогда как другие вставляют запуск xdm в скрипт rc.local (посмотрите справку по rc(8)) или X, помещая последний в каталог /usr/local/etc/rc.d. Оба метода равноправны, и один из них может работать в ситуациях, с которыми не справляется другой и наоборот. В обоих случаях результат один и тот же: X выводит графическое приглашение для входа в систему.

Плюсом метода с использованием ttys(5) является документирование того, на каком vty будет запущен X и то, что ответственность за перезапуск X-сервера при завершении сеанса работы лежит на процессе init(8). Метод с использованием rc(8) позволяет просто прекратить работу xdm командой kill xdm, если при запуске X возникли какие-нибудь проблемы.

Из rc(8) xdm должен быть запущен без аргументов. xdm должен быть запущен после запуска getty(8), иначе они будут конфликтовать, блокируя консоль. Лучше всего выдержать паузу секунд на 10 и потом запустить xdm.

Если xdm запускается из /etc/ttys, остаётся вероятность конфликта между xdm и getty(8). Одним из способов избежать этого является добавление номера vt в файл /usr/local/lib/X11/xdm/Xservers:

:0 local /usr/local/bin/X vt4

В вышеприведённом случае X-серверу указывается работать на /dev/ttyv3. Заметьте, что номера отличаются на единицу. Дело в том, что X-сервер считает vty от единицы, когда как отсчёт vty в ядре FreeBSD ведётся с нуля.

Если X запускается с помощью startx, права на устройство /dev/console не изменяются, поэтому такие программы как xterm -C и xconsole не будут работать.

Это зависит от прав доступа, установленных для консоли по умолчанию. В многопользовательской системе вовсе не нужно, чтобы любой пользователь мог выводить информацию на системную консоль. Для пользователей, вошедших в систему через VTY, для решения этой проблемы существует файл fbtab(5).

В общем, раскомментируйте строчку в файле /etc/fbtab (посмотрите справку по fbtab(5)):

/dev/ttyv0 0600 /dev/console

Этого будет достаточно для того, чтобы всякий, кто вошёл в систему с терминала /dev/ttyv0, имел доступ к консоли.

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

psmintr: out of sync (xxxx != yyyy)

Если это случилось, отмените проверку согласования, установив значение флага для драйвера мыши PS/2 в 0x100. Проще всего это сделать добавлением hint.psm.0.flags="0x100" в /boot/loader.conf с перезагрузкой.

Наберите xmodmap -e "pointer = 3 2 1". Добавьте эту команду в ~/.xinitrc или ~/.xsession для автоматического запуска.

Подробный ответ находится в разделе Загрузочные экранные заставки Руководства FreeBSD.

Да. Используйте xmodmap(1) для привязки функций к этим клавишам.

Если все клавиатуры Windows стандартны, то эти три клавиши имеют следующие клавиатурные коды:

Чтобы заставить левую клавишу Windows набирать запятую, попробуйте выполнить такую команду:

# xmodmap -e "keycode 115 = comma"

Для того, чтобы переопределения клавиш Windows выполнялось автоматически каждый раз при запуске X, поместите команды xmodmap в ~/.xinitrc либо, что предпочтительней, создайте файл ~/.xmodmaprc и включите в него параметры xmodmap по одному на строку, затем добавьте в ~/.xinitrc такую строку:

xmodmap $HOME/.xmodmaprc

Например, чтобы переопределить эти 3 клавиши так, чтобы они выполняли функции клавиш F13, F14 и F15. Это позволит легко привязать их к полезным функциям в приложениях или менеджере окон.

Чтобы сделать это, поместите такие строки в файл ~/.xmodmaprc:

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

При использовании оконного менеджера x11-wm/fvwm2 клавиши можно переопределить так, чтобы F13 сворачивал в иконку (и восстанавливал предыдущий размер) то окно, на которое указывает курсор, F14 перемещал окно с курсором на передний план или, если оно уже впереди, возвращал обратно, а F15 вызывал главное меню Workplace, даже если курсор находится не на рабочем столе, что бывает полезно, когда не видно ни одного кусочка рабочего стола.

Следующие записи в ~/.fvwmrc позволяют достичь описанных выше функций:

Key F13	FTIWS	A	Iconify
Key F14	FTIWS	A	RaiseLower
Key F15	A	A	Menu Workplace Nop

Наличие 3D-ускорения зависит от версии сервера Xorg и типа графического адаптера. Для адаптера nVidia используйте двоичный драйвер для FreeBSD, установив один из нижеследующих портов:

Последние версии адаптеров nVidia поддерживаются портом x11/nvidia-driver.

Более старые драйверы доступны как x11/nvidia-driver-###.

nVidia предоставляет подробную информацию о том, какие адаптеры поддерживаются тем или иным драйвером, на своём сайте: http://www.nvidia.com/object/IO_32667.html.

Для адаптеров Matrox G200/G400 следует попробовать порт x11-servers/mga_hal.

Для ATI Rage 128 и Radeon посмотрите страницы Справочника ati(4), r128(4) и radeon(4).

<<Бездисковая загрузка>> означает, что машина с FreeBSD загружается по сети и читает необходимые файлы с сервера, а не со своего диска. Подробное описание есть в соответствующей главе Руководства.

Да. Обратитесь к разделу Руководства, посвящённому сложным вопросам работы в сети, особенно в той части, что касается маршрутизации и маршрутизаторов.

Как правило, те, кто задают такие вопросы, имеют дома два компьютера, один с FreeBSD, а другой с какой-то версией Windows(R). Идея состоит в использовании FreeBSD для подключения к Internet, а затем осуществлять выход в Internet из Windows(R) через FreeBSD. На самом деле это просто частный случай предыдущего вопроса, который хорошо отработан.

Для подключения к Internet с использованием коммутируемого соединения нужно указать параметр -nat и установить в файле /etc/rc.conf переменную gateway_enable в значение YES. Для получения дополнительной информации обратитесь к страницам справочной системы по команде ppp(8) или разделу Руководства о PPP режима пользователя.

Если подключение к Internet выполняется через Ethernet, используйте natd(8). Вводная информация находится в разделе Руководства natd.

Да. ppp(8) может обслуживать как входящие, так и исходящие соединения.

Более подробная информация об их использовании находится в разделе Руководства о протоколе PPP.

Да. Для получения указаний по использованию NAT через подключение PPP обратитесь к разделу Руководства о PPP. Чтобы использовать NAT вместе с другим типом сетевого подключения, взгляните на раздел Руководства natd.

Если алиас находится в той же самой сети, что и уже настроенный на интерфейсе адрес, допишите к этой команде netmask 0xffffffff:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

В противном случае укажите сетевой адрес и маску обычным образом:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Дополнительная информация находится в Руководстве FreeBSD.

Некоторые версии NFS для Linux(R) поддерживают запросы на монтирование только с привилегированного порта; попробуйте выполнить следующую команду:

# mount -o -P linuxbox:/blah /mnt

В большинстве случаев проблема заключается в недостаточном понимании корректного формата файла /etc/exports. Просмотрите ещё раз справочную информацию по exports(5) и раздел об NFS в Руководстве, особенно в части настройки NFS.

Установите пакет net/mrouted и добавьте mrouted_enable="YES" в /etc/rc.conf для запуска этого сервиса во время загрузки.

За ответом на этот вопрос обращайтесь к Руководству FreeBSD.

Если ядро скомпилировано с параметром IPFIREWALL, имейте в виду, что политикой по умолчанию является запрет прохождения всех пакетов, которые явно не разрешены.

Если межсетевой экран был случайно сконфигурирован неверным образом, то для восстановления работоспособности сети наберите такую команду из-под пользователя root:

# ipfw add 65534 allow all from any to any

Рассмотрите использование firewall_type='open' в файле /etc/rc.conf.

Дополнительная информация о настройке данного межсетевого экрана находится в соответствующей главе Руководства.

Возможно, потому, что вместо простого перенаправления пакетов нужна трансляция сетевых адресов (NAT). Правило <<fwd>> только перенаправляет пакеты и данные внутри него не меняет. Рассмотрим такое правило:

01000 fwd 10.0.0.1 from any to foo 21

Когда пакет с адресом назначения foo достигает машины с этим правилом, пакет перенаправляется на 10.0.0.1, но в нём остаётся адрес назначения foo. Адрес назначения пакета не меняется на 10.0.0.1. Большинство машин, скорее всего, отбросят полученный пакет, имеющий адрес назначения, им не соответствующий. Таким образом, правило <<fwd>> не часто работает так, как ожидает пользователь. Такое поведение является особенностью, а не ошибкой.

Обратитесь к FAQ о перенаправлении сервисов, руководству по natd(8) или одной из нескольких утилит для перенаправления из Коллекции Портов для того, чтобы сделать это правильно.

Запросы FTP и других сервисов можно перенаправить с помощью порта sysutils/socket. Замените запись для этого сервиса в /etc/inetd.conf на вызов socket, как показано в этом примере для ftpd:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

где ftp.example.com и ftp являются соответственно хостом и портом для перенаправления.

Для FreeBSD имеются три средства управления трафиком. dummynet(4) интегрирован в систему FreeBSD как составная часть ipfw(4). ALTQ включен во FreeBSD как составная часть pf(4). Bandwidth Manager компании Emerging Technologies является коммерческим продуктом.

Для работы приложения требуется Berkeley Packet Filter (bpf(4)), однако это устройство удалено из вашего ядра. Постройте новое ядро с добавлением в его конфигурационный файл следующей строки:

device bpf	# Berkeley Packet Filter

Используйте пакет SMBFS. В него включён набор изменений в ядре и пользовательские программы. Программы и информация доступны как mount_smbfs(8) и входят в состав базовой системы.

Данное сообщение ядра означает, что имеет место некоторая активность, приводящая к отправке большого количества ответных пакетов ICMP или сбросов TCP (RST). Ответы ICMP часто генерируются в результате попыток подключения к незанятым портам UDP. Сбросы TCP генерируются в результате попыток подключения к закрытым портам TCP. Помимо всего прочего, такие сообщения могут быть вызваны следующими действиями:

Первое число в сообщении показывает количество пакетов, которое ядро посылало бы при отсутствии ограничений, а второе число указывает лимит. Этот лимит меняется при помощи net.inet.icmp.icmplim. В этом примере устанавливается лимит на 300 пакетов в секунду:

# sysctl net.inet.icmp.icmplim=300

Для выключения подобных сообщений без отключения самого ограничения используйте net.inet.icmp.icmplim_output, чтобы подавить вывода:

# sysctl net.inet.icmp.icmplim_output=0

И наконец, чтобы полностью выключить это ограничение, сделайте net.inet.icmp.icmplim равным 0. Выключение этого лимита не приветствуется по причинам, изложенным выше.

Это означает, что какое-то устройство в локальной сети Ethernet использует MAC-адрес в формате, неизвестном FreeBSD. Вероятно, это происходит из-за того, что кто-то в сети экспериментирует с сетевым адаптером. Чаще всего это происходит в сетях с кабельными модемами. Это безобидно и не должно влиять на производительность системы FreeBSD.

Это так, потому что пакет приходит извне сети, чего не должно быть. Чтобы отключить эти сообщения, установите net.link.ether.inet.log_arp_wrong_iface в значение 0.

<<Sandbox>> - это термин, используемый при обеспечении безопасности. Он имеет два значения:

В UNIX(R) реализованы два типа <<песочниц>>. Один на уровне процесса, и один на уровне идентификаторов пользователей.

Каждый процесс в UNIX(R) полностью защищён от других процессов. Никакой процесс не может модифицировать адресное пространство другого процесса.

В UNIX(R) каждым процессом владеет некоторый идентификатор пользователя. Если этот пользователь не root, он ограждает процесс от других, владельцами которых являются другие пользователи. Этот идентификатор используется также для защиты данных на диске.

securelevel является механизмом обеспечения безопасности, который реализован в ядре. Когда уровень защиты больше нуля, ядро ограничивает выполнение некоторых операций; даже суперпользователю root запрещается их выполнять. Механизм уровня защиты ограничивает возможности по:

Для выяснения состояния уровня защиты в работающей системе:

# sysctl -n kern.securelevel

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

Уровень защиты работающей системы не может быть понижен, поскольку это противоречит назначению этого механизма. Если для задачи требуется неположительный уровень защиты, измените значения переменных kern_securelevel и kern_securelevel_enable в файле /etc/rc.conf и перезагрузите систему.

Более подробная информация об уровнях защиты и о том, какие специфические действия выполняют все уровни, может быть найдена на справочных страницах о init(8).

Для исходящих запросов BIND использует случайно выбираемый порт с большим номером. В последних версиях при каждом запросе выбирается новый случайный порт UDP. Это может вызвать проблемы в некоторых сетевых конфигурациях, особенно если фаервол блокирует входящие UDP пакеты на определенных портах. Чтобы обеспечить прохождение пакетов через фаервол, попробуйте параметры avoid-v4-udp-ports и avoid-v6-udp-ports, чтобы предотвратить случайный выбор номеров портов, пересекающихся с блокируемым диапазоном.

Кстати, поздравляем. Прекрасно, что вы читаете вывод команды sockstat(1) и обращаете внимание на аномалии!

Последние версии Sendmail поддерживают механизм посылки почты, который работает по порту 587. Эта возможность пока широко не используется, но её популярность растёт.

Не волнуйтесь, toor является <<альтернативной>> учётной записью суперпользователя (toor - это root, записанный задом наперёд). Его предлагается использовать с нестандартным командным интерпретатором, так чтобы не нужно было менять используемый по умолчанию командный процессор для root. Это важно, так как оболочки, не являющиеся частью дистрибутива системы, устанавливаются в каталог /usr/local/bin, который по умолчанию располагается в другой файловой системе. Если командный процессор для пользователя root располагается в /usr/local/bin и файловая система, содержащая /usr/local/bin, не смонтирована, то root не сможет войти в систему для исправления проблемы и понадобится перезагрузиться в однопользовательском режиме, чтобы указать командный процессор.

Некоторые используют toor для выполнения повседневных административных работ с нестандартным командным процессором, оставляя root со стандартной оболочкой для работы в однопользовательском режиме или выполнения аварийных работ. По умолчанию пользователь не сможет войти в систему как toor, потому что для него не указан пароль, поэтому войдите из-под root и установите пароль для toor до того как использовать его для входа в систему.

Первым делом прочтите страницу Справочника ppp(8) и раздел PPP Руководства. Для помощи с устранением неполадок включите протоколирование следующей командой:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Эту команду можно набрать в командной строке ppp(8) или ввести в начале раздела default в /etc/ppp/ppp.conf. Проверьте, что файл /etc/syslog.conf содержит указанные ниже строки и существует файл /var/log/ppp.log:

!ppp
*.*    /var/log/ppp.log

Полную информацию о происходящем можно найти в файле протокола. Не беспокойтесь, если не всё будет понятно, ведь это может быть понятно кому-то ещё.

Обычно это происходит, когда имя хоста не может быть преобразовано в адрес. Наилучший способ исправить это - удостовериться, что файл /etc/hosts читается первым. Для этого нужно проверить, что в файле /etc/host.conf на первом месте стоит строчка hosts. Затем добавьте в файл /etc/hosts запись о локальной машине. Если локальная сеть отсутствует, измените строку для localhost:

127.0.0.1	foo.example.com foo localhost

В противном случае добавьте для хоста ещё одну запись. Обратитесь к соответствующим страницам Справочника за подробным описанием.

В конце убедитесь, что эта команда выполняется успешно: ping -c1 `hostname`.

Сначала проверьте наличие маршрута по умолчанию. Команда netstat -rn должна показать две строки:

Destination	Gateway	    Flags    Refs     Use     Netif Expire
default 	10.0.0.2    UGSc	0	0      tun0
10.0.0.2	10.0.0.1    UH		0	0      tun0

Если нет маршрута по умолчанию, убедитесь, что строка HISADDR была добавлена в /etc/ppp/ppp.conf.

Другая причина отсутствия строки с маршрутом по умолчанию может крыться в том, что маршрут по умолчанию был добавлен в /etc/rc.conf, и эта строка отсутствует в /etc/ppp/ppp.conf:

delete ALL

В таком случае обратитесь к соответствующему разделу Руководства.

Обычно эта ошибка появляется из-за отсутствия в файле /etc/ppp/ppp.linkup следующего раздела:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Он необходим только для динамического IP адреса или когда адрес маршрутизатора не известен. При использовании интерактивного режима можно набрать следующие команды после входа в пакетный режим. Пакетный режим обозначается заглавными буквами PPP в приглашении:

delete ALL
add 0 0 HISADDR

Обратитесь к разделу PPP и динамические IP адреса Руководства за подробной информацией.

Таймаут для PPP по умолчанию равен 3 минутам. Это может быть изменено такой строкой:

set timeout NNN

где NNN - время неактивности в секундах, после которого соединение закрывается. Если NNN равно нулю, соединение никогда не разрывается по таймауту. Эту команду можно поместить в файл ppp.conf или набрать ее в интерактивном режиме. Изменение этого параметра также возможно при активном соединении, если подключиться к сокету ppp сервера с помощью программ telnet(1) или pppctl(8). Обратитесь к страницам Справочника, посвящённым ppp(8).

Если включен Link Quality Reporting (LQR), то возможно слишком много пакетов LQR теряется в канале. ppp(8) делает вывод, что канал плох, и разрывает соединение. LQR по умолчанию выключен. Включить LQR можно так:

enable lqr

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

В большинстве модемов есть параметр, определяющий чувствительность к временной потере несущей. Обратитесь к документации модема.

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

При использовании внешнего модема проверьте утилитой ping(8), мигает ли индикатор TD при передаче данных. Если он мигает, а индикатор RD нет, проблема с той стороны. Если TD не загорается, проблема является локальной. Для внутреннего модема используйте команду set server в ppp.conf. При обрыве связи подключитесь к ppp(8) с помощью pppctl(8). Если сетевое подключение неожиданно восстанавливается при проявлении активности на диагностическом сокете или нет соединения, но команда set socket в начальный момент была выполнена успешно, то проблема имеет локальный характер. Если получается подключиться, но связи всё равно нет, включите вывод локальной отладочной информации командой set log local async и используйте ping(8) в другом окне или терминале, чтобы проверить связь. В отладочном выводе будут показаны данные, передаваемые и получаемые из канала связи. Если данные посылаются, но не принимаются обратно, то проблема с той стороны.

Теперь, после выяснения местонахождения проблемы, имеется два варианта действий:

Здесь мало что можно сделать. Большинство провайдеров отказываются помогать пользователям, которые не используют ОС от Microsoft(R). Добавьте enable lqr в /etc/ppp/ppp.conf, чтобы позволить ppp(8) отследить ошибки в удалённой системе и закрыть соединение. Такое обнаружение достаточно медленно и поэтому не так уж полезно.

Первым делом попробуйте отключить любое сжатие, указав в конфигурационном файле следующее:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Теперь попробуйте установить соединение ещё раз и удостоверьтесь, что ситуация не изменилась. Если качество соединения улучшилось или проблема оказалась полностью решённой, выясните, настройка чего приводила к проблемам методом проб и ошибок. Это полезная информация для провайдера, хотя при этом может обнаружиться, что вы работаете не с продуктом Microsoft(R).

Перед тем, как звонить провайдеру, включите вывод отладочной информации и подождите, пока соединение снова не прервётся. Для этого может потребоваться некоторое дисковое пространство. Интерес могут представлять последние прочитанные из порта данные. Обычно это данные в формате ASCII и они могут даже содержать описание проблемы (Memory fault, Core dumped).

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

В этом случае перекомпилируйте ppp(8) с отладочной информацией, и затем используйте gdb(1) для получения стека вызовов для зависшего процесса ppp. Чтобы откомпилировать программу ppp с отладочной информацией, наберите такие команды:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Затем перезапустите ppp и дождитесь следующего зависания. Когда отладочная сборка ppp(8) зависнет, запустите gdb для зависшего процесса:

# gdb ppp `pgrep ppp`

В приглашении gdb используйте команду bt или where для получения стека вызовов. Сохраните вывод сессии gdb и <<отключитесь>> от работающего процесса, выполнив команду quit в gdb.

Иногда, сразу после установления соединения, в журнале могут возникать сообщения Magic is the same. Иногда эти сообщения проходят безболезненно, а иногда одна из сторон прекращает работу. Большинство реализаций PPP не может справиться с такой ситуацией, и даже когда связь выглядит установившейся, вы будeт только бесконечно повторяющиеся конфигурационные запросы и подтверждения в файле протокола до тех пор, пока ppp(8) окончательно не закроет соединение.

Обычно это происходит на серверах с медленными дисками, на которых порт обслуживает программа getty(8), а ppp(8) выполняется из сценария регистрации или другой программы после регистрации пользователя. Были сообщения, что такое случается постоянно при использовании slirp. Причина заключается в том, что во время, проходящее между завершением работы getty(8) и запуском ppp(8), ppp(8) со стороны клиента начинает посылать пакеты Line Control Protocol (LCP). Так как режим эха остаётся всё ещё включенным, ppp(8) клиента получает <<отражения>> своих запросов.

Частью процесса согласования параметров LCP является определение <<магического>> числа для каждой стороны соединения для обнаружения <<отражений>>. Согласно спецификации, когда одна сторона пытается использовать совпадающее "магическое" число, должен быть послан ответ NAK и должно быть выбрано новое "магическое" число. В тот момент, когда на порту сервера включен режим эха, клиент ppp(8) посылает пакеты LCP, получает то же самое "магическое" число в отражённом пакете и отвечает на него NAK. Он также видит отражённый NAK (который также означает, что ppp(8) должен изменить своё "магическое" число). В потенциале это может вызвать появление огромного количества процессов смен "магических" чисел, и все они накапливаются в буфере терминала. Как только запустится сервер ppp(8), он будет перегружен запросами на смену "магических", немедленно решит, что этого много для согласования LCP и прервёт соединение. В то же самое время, клиент, который больше не видит отражений, останавливается для того, чтобы увидеть, что сервер закрыл соединение.

Этого можно избежать, позволив начинать согласование противоположной стороне следующей строкой в файле ppp.conf:

set openmode passive

Это заставит ppp(8) ожидать начала согласования LCP. Некоторые серверы, однако, могут никогда не начать согласование. В этом случае попробуйте сделать следующее:

set openmode active 3

Это заставит ppp(8) пассивно ждать 3 секунды, и только затем посылать запросы LCP. Если противоположная сторона начнёт посылать в этот момент запросы, ppp(8) немедленно ответит, не ожидая истечения трёхсекундного интервала.

В настоящий момент одной из неприятных особенностей реализации ppp(8) является то, что она не связывает сообщения LCP, CCP & IPCP с запросами. Как результат, если реализация PPP с одной стороны более чем на 6 секунд медленнее, чем с другой, противоположная сторона будет посылать два дополнительных запроса на согласование параметров LCP. Это фатально.

Предположим, что у нас работают две реализации, на машинах A и B. A начинает посылать запросы LCP сразу же после соединения, а B требуется 7 секунд для запуска. Когда B запускается, A послало 3 LCP-запроса. Полагаем, что режим эха выключен, в противном случае мы столкнулись бы с проблемами "магического" числа, описанными в предыдущем разделе. B посылает REQ, затем ACK на первый REQ от A. Это приводит к тому, что A входит в состояние OPENED и посылает (первый) ACK обратно B. В то же самое время B посылает обратно ещё два ACK в ответ на два дополнительных REQ, посланные A до старта B. B затем получает первый ACK от A и возвращается в состояние REQ-SENT, послав ещё один (четвёртый) REQ согласно RFC. Затем он получает третий ACK и входит в состояние OPENED. В это же время B принимает четвёртый REQ от A, что возвращает его в состояние ACK-SENT и посылает ещё один (второй) REQ и (четвёртый) ACK согласно RFC. A получает REQ, переходит в состояние REQ-SENT и посылает ещё один REQ. Он немедленно принимает последующий ACK и входит в состояние OPENED.

Это будет продолжаться до тех пор, пока одна из сторон не обнаружит, что это ни к чему не приводит и не закроет соединение.

Лучшим способом избежать этой ситуации является конфигурация одной из сторон как passive, чтобы она ждала другую для начала согласования. Это можно сделать следующей командой:

set openmode passive

С этой командой нужно быть осторожным. Эту команду можно также использовать для ограничения периода ожидания, в течении которого ppp(8) ждёт начала согласования с противоположной стороны:

set stopped N

Как вариант, может быть использована следующая команда (где N - период ожидания в секундах перед тем, как начать согласование):

set openmode active N

За дополнительной информацией обращайтесь к странице Справочника.

При использовании shell или ! ppp(8) запускает оболочку или переданные параметры. Программа ppp будет ждать окончания выполнения команды, прежде чем продолжить. При любой попытке воспользоваться связью PPP во время выполнения команды связь будет выглядеть заблокированной. Это происходит из-за того, что ppp(8) ждёт завершения команды.

Для выполнения подобных команд используйте вместо этого !bg. В этом случае нужная команда будет выполняться в фоновом режиме, а ppp(8) сможет продолжить обслуживание канала связи.

ppp(8) не может определить, что соединение было закрыто. Это происходит из-за метода использования сигнальных линий нуль-модемного кабеля. При использовании такого типа соединения всегда включайте LQR:

enable lqr

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

Если ppp(8) начинает неожиданно звонить, определите причину и настройте фильтры дозвона для предотвращения подобных звонков.

Для выяснения причины такого поведения, используйте строку:

set log +tcp/ip

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

Теперь отключите дозвон при данных условиях. Как правило, такие проблемы возникают из-за обращений к DNS. Для предотвращения обращений к DNS и установления соединения (что не запретит ppp(8) пропускать пакеты через уже установленное соединение), используйте такую комбинацию:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

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

В случае DNS попытайтесь установить, что именно пытается определить имя хоста. В большинстве случаев виновным оказывается Sendmail. Проверьте, чтобы в конфигурационном файле программы Sendmail не было указано обращаться к DNS. Обратитесь к разделу об использовании электронной почты при коммутируемом соединении в Руководстве FreeBSD за подробным описанием. Вам может понадобиться добавить в файл .mc строку:

define(`confDELIVERY_MODE', `d')dnl

Это заставит Sendmail добавлять все сообщения в очередь до тех пор, пока не будет запущена её обработка, как правило, каждые 30 минут, или пока не будет выполнена команда sendmail -q, возможно, из файла /etc/ppp/ppp.linkup).

В файле протокола появляются такие сообщения об ошибках:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Это происходит, если ppp(8) пытается установить сжатие Predictor1, а противоположная сторона не хочет устанавливать никакого сжатия. Эти сообщения безобидны, но их можно заглушить отключением сжатия:

disable pred1

Для записи полного протокола взаимодействия с модемом включите следующее:

set log +connect

Это заставит ppp(8) протоколировать всё, вплоть до последней прочтённой через <<expect>> строки.

Чтобы увидеть скорость соединения при использовании PAP или CHAP, укажите ppp(8) ожидать полную строку CONNECT:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Здесь мы получаем строку CONNECT, ничего не посылаем, а затем ожидаем символа перевода строки, заставляя ppp(8) читать целиком содержимое ответа CONNECT.

Программа ppp разбирает каждую строку в конфигурационных файлах и поэтому может правильно интерпретировать строки вида set phone "123 456 789" и обнаруживать, что на самом деле номер является единственным аргументом. Для того, чтобы указать символ ", заэкранируйте его символом обратного слэша (\).

Когда интерпретатор chat разбирает каждый параметр, он ещё раз просматривает аргумент на предмет каких-либо специальных последовательностей типа \P или \T. Вследствие этой двойной интерпретации не забывайте об использовании нужного количества экранирующих символов.

Чтобы передать сам символ \, укажите что-то типа:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Это приведёт к такой последовательности:

ATZ
OK
AT\X
OK

Или:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Это даст такую последовательность:

ATZ
OK
ATDT1234567

Эта проблема проявлялась, когда ppp(8) в режиме -auto был настроен на динамическое согласование локального IP-адреса с противоположной стороной. Это было давно исправлено - поищите на странице справочника слово iface.

Причиной было то, что когда эта программа использует системный вызов connect(2), для сокета назначается IP-адрес интерфейса tun(4). Ядро создаёт первый исходящий пакет и записывает его в устройство tun(4). Затем ppp(8) читает пакет и устанавливает соединение. Если в результате согласования ppp(8) динамического IP-адреса адрес интерфейса изменится, сокет будет работать некорректно. Любые IP-пакеты, передаваемые через сокет, будут отброшены. Если даже этого не произойдёт, ответные данные не будут достигать отправителя, так как этот адрес больше ему не принадлежит.

Теоретически есть несколько способов решить эту проблему. Лучше всего, если противоположная сторона назначит интерфейсу тот же самый IP-адрес. Текущая версия ppp(8) именно так и поступает, но большинство других реализаций этого не делают.

Самым простым решением будет просто никогда не менять IP-адрес интерфейса tun(4), а вместо этого изменять на лету все исходящие пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса на соответствующий с противоположной стороны. Это, в сущности, то же самое, что делает опция iface-alias в самой последней версии ppp(8) (с помощью библиотеки libalias(3) и ключа -nat для ppp(8)) - она отслеживает все назначенные ранее интерфейсу адреса и замещает их на последний из назначенных.

Другой возможный (и, наверное, самый надёжный) способ - это создать системный вызов, меняющий IP-адреса всем уже связанным сокетам. ppp(8) использовал бы этот вызов для модификации сокетов всех работающих программ после согласования нового IP-адреса. Этот же самый системный вызов могли бы использовать клиенты DHCP, когда они осуществляют повторную привязку к сокету, вызывая для этого функцию bind().

Ещё одной возможностью является разрешение интерфейсу становиться активным без IP-адреса. Исходящим пакетам будет даваться IP адрес 255.255.255.255 до первого вызова ioctl(2) SIOCAIFADDR, приводящего к полной привязке сокета. ppp(8) нужно будет изменять исходящий IP-адрес и контрольную сумму пакета, только если он установлен в 255.255.255.255. Это, однако, является некоторым хаком, так как ядро будет посылать некорректные пакеты на не полностью сконфигурированный интерфейс, в предположении, что существует механизм исправления этих пакетов.

FCS является сокращением от Frame Check Sequence (контроль последовательности кадров). Каждый кадр PPP имеет контрольную сумму для проверки того, что принятые данные совпадают с переданными. Если FCS принятого пакета некорректна, пакет отбрасывается и счётчик FCS для HDLC увеличивается. Значения ошибок уровня HDLC можно вывести командой show hdlc.

Если линия плохого качества или драйвер коммуникационного адаптера отбрасывает пакеты, будут появляться случайные ошибки FCS. Это обычно не является причиной для волнений, хотя это существенно замедляет протоколы компрессии.

Если связь замирает сразу при установлении соединения и наблюдается большое количество ошибок FCS, убедитесь, чтобы модем не использовал программное управление потоком (XON/XOFF). Если же для соединения должно использоваться программное управление потоком, то воспользуйтесь командой set accmap 0x000a0000 для указания ppp(8) экранировать символы ^Q и ^S.

Другой причиной слишком большого количества ошибок FCS может быть прекращение противоположной стороной сеанса PPP. В этом случае включите протоколирование async для проверки того, не являются ли поступаемые из линии данные на самом деле приглашением login или shell. Если с противоположной стороны находится приглашение shell, завершить ppp(8) без обрыва связи можно командой close lcp и последующей командой term, чтобы переподключиться к приглашению shell на удалённой машине.

Если ничего в файле протокола не говорит о причине разрыва связи, спросите у администратора удалённой машины или вашего провайдера, почему сеанс был закрыт.

Если всё уже перепробовано, и ничего не получается, пошлите подробности об ошибке, конфигурационные файлы, способ запуска ppp(8), соответствующие части файла протокола, и вывод команды netstat -rn до и после соединения в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD.

Список таких устройств находится в главе Руководства Последовательные соединения.

Большинство многопортовых PCI адаптеров на базе 16550 и их клоны поддерживаются без дополнительных усилий.

Некоторые безымянные клоны таких адаптеров тоже работают нормально, особенно те, которые заявляют о своей совместимости с AST.

Прочтите страницы Справочника uart(4) и sio(4) для получения подробной информации о конфигурировании таких адаптеров.

Подробная информация находится в этом разделе Руководства.

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

% dmesg | grep -E "^sio[0-9]"
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

Здесь присутствуют два последовательных порта. Первый находится на IRQ4, порт ввода/вывода 0x3f8, и построен на микросхеме UART типа 16550A. Второй использует тот же тип микросхемы, но находится на IRQ3 и использует адрес порта ввода/вывода 0x2f8. Внутренние модемы выглядят точно также, как последовательные порты, за исключением того, что модем к ним подключен всегда.

В ядро GENERIC встроена поддержка двух последовательных портов, с теми же IRQ и адресами портов ввода/вывода, как указано в примере выше. Если эти настройки не соответствуют системе или имеется больше внутренних модемов или последовательных портов, чем описано в ядре, переконфигурируйте его, следуя инструкциям в разделе о построении ядра.

Третий последовательный порт, sio2 или COM3, обозначается как /dev/cuad2 для устройств, выполняющих исходящие звонки, и /dev/ttyd2 для устройств, принимающих входящие звонки. Какая разница между этими двумя классами устройств?

При открытии /dev/ttydX в блокирующем режиме процесс будет ожидать неактивности соответствующего устройства cuadX, а затем появления сигнала о наличии несущей. При открытии устройства cuadX он проверяет, что последовательный порт не занят устройством ttydX. Если порт доступен, он похищает его у устройства ttydX. Также устройство cuadX не следит за наличием несущей. С такой схемой работы и модемом в режиме автоответа удалённые пользователи могут входить в систему, а локальные пользователи через тот же модем могут по прежнему осуществлять исходящие звонки, а система позаботится о возможных конфликтах.

Информация о конфигурировании ядра содержится в соответствующем разделе, посвящённом этому вопросу. Для многопортовых последовательных адаптеров добавьте в файл device.hints(5) по строке sio(4) на каждый порт. Но IRQ должен быть указан только у одного порта. Все порты на адаптере должны использовать одно и то же значение IRQ. Для обеспечения согласованности используйте для указания IRQ последний последовательный порт. Также укажите следующую опцию в файле конфигурации ядра:

COM_MULTIPORT

В следующем примере указано содержимое /boot/device.hints для 4-портового последовательного адаптера AST на IRQ 12:

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

Флаги указывают, что управляющий порт имеет младший номер устройства 7 (0x700), и все порты совместно используют один и тот же номер IRQ (0x001).

Смотрите раздел Руководства FreeBSD, посвящённый последовательным соединениям.

Ознакомьтесь с разделом Руководства FreeBSD, посвящённым входящим соединениям.

Информация по этому вопросу находится в разделе Терминалы Руководства FreeBSD.

Встроенные утилиты tip(1) и cu(1) могут получить доступ к каталогу /var/spool/lock только из-под пользователя uucp и членов группы dialer. Используйте группу dialer для управления доступом к модему или удалённым системам посредством добавления в неё пользовательских учётных записей.

Либо же можно разрешить всем запускать tip(1) и cu(1):

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip

FreeBSD активно перемещает неиспользуемые страницы памяти, к которым не было обращений, в раздел подкачки, чтобы увеличить объём доступной физической памяти для активного использования. Такое активное использование раздела подкачки компенсируется использованием дополнительной свободной оперативной памяти для кеширования.

Заметьте, что хотя FreeBSD предпочитает использовать раздел подкачки, страницы не перемещаются произвольно при полностью неактивной системе. По этой причине система не будет находиться целиком в разделе подкачки после ночного простаивания.

Просто дело в том, что под свободной памятью подразумевается никак не используемая память. Вся память, которая программам явно не выделялась, используется ядром FreeBSD для дискового кэша. Значения, показываемые утилитой top(1), помеченные как Inact, Cache и Buf - это всё кэшированные данные разных степеней устаревания. То, что данные находятся в кэше, означает, что система не будет обращаться к медленному диску снова за теми данными, обращение к которым было недавно, повышая таким образом общую производительность. В общем случае маленькие значения в пункте Free, показываемые утилитой top(1) для свободной памяти - это хорошо, если, конечно они не очень маленькие.

Символические ссылки не имеют атрибутов доступа, и по умолчанию утилита chmod(1) следует по символической ссылке, чтобы по возможности изменить права доступа на исходный файл. Для файла foo с символической ссылкой bar на этот файл эта команда всегда будет выполняться успешно.

% chmod g-w bar

Однако права на файл bar не изменятся.

Чтобы это работало, используйте опцию -H или -L вместе с опцией -R. Обратитесь к страницам Справочника по команде chmod(1) и по symlink(7).

% chmod 555 foo/

Да. Программа эмуляции DOS emulators/doscmd включена в Коллекцию Портов FreeBSD.

Если doscmd не достаточно, emulators/pcemu эмулирует 8088 и набор сервисов BIOS, достаточный для запуска многих приложений текстового режима DOS. Требуется X Window System.

В Коллекции Портов FreeBSD также имеется emulators/dosbox. Программа в основном предназначена для эмуляции старых игр, написанных под DOS, для хранения файлов которых используется локальная файловая система.

Ознакомьтесь с FAQ по Переводам из FreeBSD Documentation Project Primer.

В почтовой системе FreeBSD.org в Postfix применяются некоторые проверки входящей почты, и отвергаются сообщения, которые были неправильно сформированы при пересылке либо как-то иначе похожи на спам. Некоторые из требований:

Дополнительные советы по доставке письма:

Если у вас всё ещё остались трудности при работе с почтовой инфраструктурой FreeBSD.org, отправьте сообщение с подробным описанием на адрес <postmaster@freebsd.org>. Укажите в нём временной интервал для проверки логов - и обратите внимание, что мы держим журнал почтовых логов всего за неделю. (Обязательно укажите часовой пояс или разницу в UTC.)

Хотя FreeBSD не предоставляет бесплатный доступ ни к одному из своих серверов, другие компании предоставляют UNIX(R)-системы с открытым доступом. Стоимость этой услуги различна, также как и ограниченный набор услуг.

Arbornet, Inc, также известный как M-Net, предоставляет свободный доступ к UNIX(R)-системам с 1983 года. Начиная на платформе Altos с работающей System III, сайт перешёл на BSD/OS в 1991. В июне 2000 сайт сменил систему снова, теперь на FreeBSD. M-Net может быть доступна через протоколы telnet и SSH и предоставляет доступ к полному набору программного обеспечения FreeBSD. Однако доступ к сети ограничен для членов и спонсоров, которые поддерживают систему, которая работает как неприбыльная организация. M-Net предоставляет также услуги электронной доски объявлений (BBS) и интерактивного чата.

У него нет определённого имени, он называется просто <<даемон BSD>>. Если вам непременно нужно имя, называйте его <<beastie>>. Заметьте, что <<beastie>> произносится как <<BSD>>.

Больше о даемоне BSD можно узнать из его домашней страницы.

Вполне. Права на даемона BSD имеет Marshall Kirk McKusick. Для выяснения подробностей относительно правил его использования обратитесь к странице автора Statement on the Use of the BSD Daemon Figure.

В общем, использовать изображение можно в высокохудожественном стиле и в личных целях, если даются соответствующие отсылки. Перед использованием знака в коммерческих целях обратитесь за разрешением к Kirk McKusick <mckusick@FreeBSD.org>. Дополнительная информация находится на домашней странице Даемона BSD.

В каталоге /usr/share/examples/BSD_daemon/ есть рисунки в форматах eps и Xfig.

Пожалуйста, обращайтесь к Глоссарию FreeBSD.

На самом деле, очень краткий ответ на этот вопрос заключается в том, что вы этого делать не должны. Если давать более подробный ответ, то ваше умение делать навесы не должно означать, что вы должны препятствовать другим делать их просто потому, что вам не нравится цвет, в который они собираются их окрашивать. Эта метафора означает, что вам не нужно обсуждать каждую мелочь просто потому, что вы знаете о ней достаточно много. Некоторые люди отмечают, что объём шума, генерируемый при появлении некоторого изменения, находится в обратной зависимости от сложности самого изменения.

Более пространный и полный ответ заключается в том, что после очень долгого обсуждения того, должна ли утилита sleep(1) обрабатывать дробное число, заданное в качестве второго аргумента, Poul-Henning Kamp <phk@FreeBSD.org> опубликовал большое сообщение, озаглавленное << Велосипедный навес (подставьте здесь цвет) на зелёной траве...>>. Соответствующие части этого сообщения цитируются ниже.

В. Кто-нибудь делал замеры температуры при работе FreeBSD? Я знаю, что Linux(R) греется меньше, чем DOS, но никогда не видел упоминания FreeBSD. Наверное, он сильно греется.

О. Нет, но мы сделали различные вкусовые тесты у добровольцев с завязанными глазами, которые до этого приняли по 250 микрограмм LSD-25. 35% добровольцев заявило, что FreeBSD имеет вкус апельсина, тогда как вкус Linux(R) расценивался как фиолетовый туман. Ни одна из групп не отметила значительной разницы в температуре. Мы хотели опубликовать полные результаты этого опроса, когда обнаружили, что слишком много добровольцев покинули помещение во время тестов, что несколько смазало результаты. Думаем, что большинство из них работают сейчас в Apple над их новым GUI <<чеши и нюхай>>. Это старый добрый бизнес!

Если серьёзно, то FreeBSD использует инструкцию HLT (halt), когда система простаивает, что уменьшает потребление энергии и, в свою очередь, выделение тепла. Вдобавок, если у вас настроен ACPI (усовершенствованный интерфейс управления конфигурацией и питанием), то FreeBSD может переводить процессор в режим пониженного энергопотребления.

В. Делает ли FreeBSD что-нибудь <<эдакое>> при компиляции ядра, что вызывает поскрипывание микросхем памяти? При компиляции (и в короткий промежуток времени после обнаружения дисковода при старте системы) от микросхем памяти исходит странный царапающий звук.

О. Да! Вы, наверное, видели частое упоминание <<даемонов>> в документации по BSD, но не многие знают, что это настоящие нематериальные существа, которые теперь завладели вашим компьютером. Царапающий звук, издаваемый микросхемами памяти - это на самом деле высокочастотное перешёптывание между даемонами, когда они решают, как лучше справиться с различными задачами по администрированию системы.

Если шум достиг ваших ушей, команда DOS fdisk /mbr их спугнёт, но не удивляйтесь, если они отреагируют соответствующим образом и попытаются вас остановить. Фактически, если во время выполнения этой команды вы услышите сатанинский голос Билла Гейтса из встроенного динамика, бегите и даже не оглядывайтесь! Избавленные от противостояния с даемонами BSD, близнецы-демоны DOS и Windows(R) часто могут захватить полный контроль не только над вашей машиной и навлечь вечное проклятие на вашу душу. Теперь, когда вы это знаете, если бы у вас был выбор, думаем, что вы бы предпочли слышать царапающий звук, не так ли?

Необходимо иметь ровно одну тысячу сто шестьдесят девять разработчиков:

Двадцать три сообщат в -CURRENT о том, что не горит свет;

Четыре начнут утверждать, что это проблема конфигурации и такие сообщения нужно посылать в -questions;

Трое оформят PR по этому поводу, причём одно их них будет направлено в doc и будет содержать только строчку <<здесь темно>>;

Один закоммитит неоттестированную лампочку, что сломает построение системы, а затем через пять минут вернёт всё назад;

Восемь поругаются с авторами PR по поводу включения патчей в PR;

Пять сообщат о том, что не проходит компиляция системы;

Тридцать один человек ответит, что у них всё работает и наверное, те обновились в неподходящее время;

Один пошлёт патч для новой лампочки в -hackers;

Один пожалуется, что у него имелись патчики ещё три года назад, но когда он послал их в -CURRENT, они были проигнорированы и он имел неудачный опыт работы с системой PR; кроме того предлагаемая лампочка не имеет отражателя.

Тридцать семь начнут кричать, что лампочки не относятся к базовой системе, что коммиттеры не имеют права делать такие вещи без опроса общественности и ЧТО ВООБЩЕ -CORE ДЕЛАЕТ ПО ЭТОМУ ПОВОДУ?

Две сотни напишут о цвете велосипедного навеса;

Трое скажут, что этот патч не соответствует style(9)

Семнадцать возразят, что предлагаемая новая лампа подпадает под лицензию GPL;

Пятьсот восемьдесят шесть раздуют флейм по поводу сравнения лицензий GPL, BSD, MIT, NPL и личных мнений о неизвестных основателей FSF;

Семеро пошлют различные части этих обсуждений в -chat и -advocacy;

Один закоммитит предлагаемую лампу, хотя она светит хуже, чем старая;

Двое откатят эти изменения с ужасной руганью в журнале коммитта о том, что лучше FreeBSD будет сидеть в темноте, чем с тусклой лампой.

Сорок шесть громко воспротивятся этому изменению и потребуют объяснений от -core;

Одиннадцать попросят уменьшить размер лампочки, чтобы она подошла к их Тамагочи на случай, если мы когда-нибудь соберёмся переносить FreeBSD на эту платформу;

Семьдесят три заявят о SNR в -hackers и -chat и в знак протеста отпишутся;

Тринадцать пошлют письма <<unsubscribe>>, <<How do I unsubscribe?>> или <<Please remove me from the list>> с обычной подписью;

Один закоммитит работающую лампочку в то время, как все будут слишком заняты руганью, чтобы это заметить;

Тридцать один человек напишет, что новая лампочка будет светить на 0.364% ярче, если её откомпилировать с помощью TenDRA (хотя при этом она приобретёт форму куба) и что FreeBSD должна перейти на компилятор TenDRA, а не на GCC;

Один заметит, что у лампочки отсутствует цоколь;

Девять (включая авторов PR) спросят <<что такое MFC?>>;

Спустя две недели после смены лампочки пятьдесят семь человек сообщат о том, что света всё равно нет.

Nik Clayton <nik@FreeBSD.org> добавил:

Я сильно смеялся над всем этим.

И тогда я подумал, <<Постойте-ка, найдётся ли кто-нибудь, чтобы задокументировать это?>>

И на меня снизошло озарение :-)

Thomas Abthorpe <tabthorpe@FreeBSD.org> говорит: <<Нет, настоящие хакеры FreeBSD не боятся темноты!>>

Они отправляются в специальную сточную трубу для данных в CPU, где преобразуются в тепло, выдуваемое через охлаждающие вентиляторы. Вот почему охлаждение ЦП становится все более важным; так как люди используют все более быстрые процессоры, они все менее заботятся о данных, все большее их количество оканчивает свой путь в /dev/null, перегревая ЦП. Если вы удалите /dev/null (что соответственно отключит трубу данных в ЦП), то ваш процессор может охладиться, но система начнет переполняться излишними данными и начнет работать с ошибками. Если у вас быстрое сетевое подключение, вы можете охладить CPU, читая данные из /dev/random и посылая их куда-нибудь; однако вы рискуете перегреть ваше сетевое соединение и / или разозлить вашего провайдера, так как большинство данных преобразуется в тепло на его оборудовании, но, как правило, у него хорошее охлаждение, так что если вы не перестараетесь, все должно быть в порядке.

Пол Робинсон (Paul Robinson) добавляет:

Есть и другие методы. Как знает каждый хороший системный администратор, частью хорошей практики является посылка данных на экран интересным образом, чтобы феи, которые образуют картинку, были счастливы. Экранные феи (часто неправильно называемые <<пикселами>>) различаются по цвету головных уборов, которые они носят (красные, зеленые или синие), и прячутся или появляются (показывая, таким образом, цвет своих шляп), когда получают немного пищи. Видеоадаптеры преобразуют данные в еду для фей, а затем посылают ее феям - чем дороже адаптер, тем лучше еда, тем лучше ведут себя феи. Они также нуждаются в постоянной стимуляции - вот зачем нужны хранители экранов.

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

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

Список относящихся к делу книг можно найти в разделе Руководства Библиография по внутреннему устройству операционной системы.

Кроме того, большинство общих знаний о UNIX(R) непосредственно применимо к FreeBSD.

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

В Хранилище Subversion сейчас находятся 4 активно/полуактивно развивающихся ветки FreeBSD. (Более ранние ветки изменяются очень редко, именно поэтому в разработке только 4 активные ветки):

HEAD - это не настоящий тэг ветки. Это символьная константа для обозначения текущего, не ветвящегося, находящегося в разработке дерева, то есть -CURRENT.

На данный момент -CURRENT является находящимся в разработке деревом 11.X; ветка 10-STABLE, stable/10/, отделилась от -CURRENT в январе 2014 года года, а ветка 9-STABLE, stable/9/, отделилась от -CURRENT в сентябре 2011 года.

Да, это можно делать без скачивания полного дерева исходных текстов с помощью системы CTM.

Обратитесь к статье о том, как помочь проекту FreeBSD, чтобы выяснить, как это сделать.

И спасибо Вам за Ваши усилия!

Вот типичная паника ядра:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Этого сообщения не достаточно. Здесь важно значение указателя инструкций, но оно зависит от конфигурации, поскольку значение меняется для каждого конкретного файла ядра. Если это ядро GENERIC из одного из снэпшотов, то кто-то ещё может отследить функцию, вызвавшую ошибку, но в случае со специально сконфигурированным ядром только вы можете сказать нам, где случилась ошибка.

Чтобы продолжить:

Тем не менее, лучшим способом выяснить причину, вызвавшую аварийный останов, является получение аварийного дампа системы, а затем использование kgdb(1) для получения трассировки вызовов в этом дампе.

В любом случае, метод таков:

В процессе выполнения команды make(1) будут построены два ядра, /usr/obj/usr/src/sys/MYKERNEL/kernel и /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel будет установлен как /boot/kernel/kernel, тогда как kernel.debug может быть использован в качестве источника отладочных символов для kgdb(1).

Чтобы получать аварийный дамп, отредактируйте файл /etc/rc.conf так, чтобы устройство dumpdev указывало на раздел подкачки или имело значение AUTO. В этом случае скрипты rc(8) будут вызывать команду dumpon(8) для создания аварийных дампов. Эту команду можно также запускать вручную. После аварийной остановки аварийный дамп может быть получен с помощью программы savecore(8) если значение переменной dumpdev было установлено в /etc/rc.conf, скрипты rc(8) запустят savecore(8) автоматически и поместят аварийный дамп в каталог /var/crash.

Как только аварийный дамп получен, трассировку вызовов можно получить таким образом:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Заметьте, что это может дать несколько экранов полезной информации. Лучше всего использовать script(1) для перехвата всего вывода. При использовании необработанного файла ядра со всей отладочной информацией может быть найдена конкретная строка исходного текста ядра, при достижении которой случилась аварийная остановка. Для выяснения последовательности событий, приведших к аварийному останову, трассировка стека обычно читается снизу вверх. Также можно использовать kgdb(1) для вывода значений различных переменных или структур, чтобы выяснить состояние системы во время аварии.

По умолчанию при работе с форматом ELF символы, определённые в исполняемом файле, не доступны динамическому загрузчику. Поэтому при вызове функции dlsym(), которая осуществляет поиск по дескриптору, полученному после вызова dlopen(NULL, flags), желаемый результат достигнут не будет.

Чтобы осуществить поиск символов в исполняемом файле процесса с помощью функции dlsym(), выполните компоновку исполняемого файла с параметром --export-dynamic компоновщика ELF (ld(1)).

По умолчанию размер адресного пространства ядра для i386 равен 1 Гбайт (2 Гбайт для PAE). Для работы сервера с интенсивной сетевой нагрузкой или при использовании ZFS этого может быть недостаточно.

Чтобы увеличить доступное пространство, добавьте следующую строку в файл конфигурации ядра и пересоберите ядро:

options KVA_PAGES=N

Чтобы получить нужное значение для N, разделите желаемый размер адресного пространства (в мегабайтах) на четыре (для 2 Гбайт это будет 512).