 | Чтобы изменить какие-либо файлы, которые система исполняет в процессе запуска, необходимо войти в систему как пользователь root. |
Управление процессом загрузки вашего компьютера
Статья включает:
Подробности процесса запуска системы зависят от оборудования компьютера. В этом разделе приводится лишь общее описание запуска операционной системы ЗОСРВ «Нейтрино».
| Чтобы изменить какие-либо файлы, которые система исполняет в процессе запуска, необходимо войти в систему как пользователь root. |
При загрузке системы процессор сбрасывается и исполняет команду, на которую указывает его вектор сброса. Вектор сброса процессоров семейства x86 обычно указывает на BIOS, однако на других платформах вектор сброса может указывать на ПЗУ-монитор или команду прямого перехода на код начального загрузчика платы. После запуска ПЗУ-монитор обычно передает управление начальному загрузчику. BIOS делает то же самое либо непосредственно передает управление началу образа операционной системы (рис. 1).
Начальный загрузчик (IPL) копирует загрузочный образ в память и переходит на код начальной загрузки. Код запуска инициализирует оборудование, заполняет системную страницу информацией об оборудовании, загружает функции межбиблиотечных вызовов, которые используются ядром для взаимодействия с оборудованием, а затем загружает и запускает микроядро и администратор процессов — модуль procnto (который также поддерживает именованные семафоры). Начальный загрузчик и код начальной загрузки, как правило, входят в состав BSP-пакета для конкретной платы.
После завершения своей инициализации модуль procnto выполняет команды, помещенные в загрузочный сценарий, которые позволяют продолжить настройку среды исполнения с помощью сценария командного интерпретатора или программы, написанной на языке C и/или C++.
Если система имеет процессор, который не принадлежит к семейству x86, и загружается с диска, то процесс настройки прост: большую его часть выполняет загрузочный сценарий или сценарий командного интерпретатора, который вызывается загрузочным сценарием.
Загрузка системы с архитектурой x86 с использованием BIOS выполняется сложнее (рис. 2).
Получив управление, BIOS конфигурирует оборудование, а затем проверяет наличие сигнатур расширений BIOS (0x55AA). BIOS вызывает свои расширения (например, сетевая плата с загрузочным ПЗУ или контроллером жесткого диска) до тех пор, пока одно из них не выполнит загрузку системы. Если ни одно расширение не загружает систему, BIOS выводит сообщение об ошибке (как правило, странное).
При сетевой загрузке аппаратный загрузчик (как правило, bootp) загружает образ с сервера, копирует его в память, а затем передает управление началу образа. Поскольку загрузочному образу обычно необходимо использовать стек сетевого протокола, он запускает какую-либо сетевую файловую систему, чтобы загрузить дополнительные программы и файлы или получить к ним доступ.
Чтобы создать образ операционной системы, можно воспользоваться утилитой mkifs. Пример файла построения образа операционной системы см. в приложении.
Процесс загрузки операционной системы ЗОСРВ «Нейтрино» с диска более сложен, а инициализация системы – еще сложнее. После того как BIOS выберет загрузку с жесткого диска, вызывается первичный загрузчик (который иногда называют загрузчиком раздела). Этот загрузчик "индифферентен" по отношению к операционной системе, т.е. способен загрузить любую операционную систему. Загрузчик, который устанавливается ЗОСРВ «Нейтрино», отображает следующее сообщение:
Press F1-F4 to select drive or select partition 1,2,3? 1 (Нажмите клавишу F1-F4 для выбора диска или раздела 1, 2, 3? 1)
После короткой паузы загружается операционная система, которая расположена в выбранном разделе. Эта загрузка выполняется вторичным загрузчиком. Записать его на диск можно с помощью утилиты dinit или mkqnx6fs в зависимости от типа файловой системы.
При выборе раздела с ОС запускается вторичный загрузчик (который иногда называют загрузчиком операционной системы). Этот загрузчик специфичен для операционной системы ЗОСРВ «Нейтрино» и располагается в соответствующем разделе жесткого диска. При использовании таблицы MBR (в BIOS-системах) загрузчик размещается в файловой системе fs-qnx6.so или fs-qnx4.so. При использовании таблицы GPT (в UEFI-системах) загрузчик размещается в отдельном разделе с файловой системой FAT32.
Далее приводятся общие сведения по созданию таблиц разделов.
Таблица разделов Master Boot Record (MBR) используется в BIOS-системах для разметки разделов жестких дисков. Для ее модификации используется утилита fdisk.
Рассмотрим процедуру разметки пустого жесткого диска. Первым делом следует очистить следы предыдущей таблицы разделов. Если имеется GPT таблица, удалить ее можно с помощью команды z интерактивного режима утилиты gdisk:
gdisk /dev/hd0
Следующее сообщение сигнализирует о том, что GPT таблица не была найдена:
Error: bad GPT header size -2094167194 Error: GPT header verification gdisk: gpt_header_read() can't read GPT header information
В этом случае для удаления разделов достаточно воспользоваться утилитой fdisk (в случае, если используется таблица MBR):
fdisk /dev/hd0 delete -a sleep 1 mount -e /dev/hd0
или выполнить команду:
dd if=/dev/zero of=/dev/hd0 bs=1024 count=64
Создание нового раздела размером 24Gb для файловой системы Power-Safe для последующей установки ОС:
fdisk /dev/hd0 add -t 177 24G sleep 1 mount -e /dev/hd0
Форматирование рабочего раздела операционной системы:
mkqnx6fs -q /dev/hd0t177
Установка первичного загрузчика может быть произведена командой:
fdisk /dev/hd0 loader
Таблица разделов GUID Partition Table (GPT) является частью стандарта EFI (Extensible Firmware Interface). Для модификации таблицы разделов данного типа используется утилита gdisk.
В таблице GPT каждый разделы идентифицируются уникальными UUID. Рассмотрим процедуру разметки пустого жесткого диска. Первым делом следует очистить следы предыдущей таблицы разделов. Если уже имеется GPT таблица, удалить ее можно с помощью команды z интерактивного режима утилиты gdisk:
gdisk /dev/hd0
Следующее сообщение сигнализирует о том, что GPT таблица не была найдена:
Error: bad GPT header size -2094167194 Error: GPT header verification gdisk: gpt_header_read() can't read GPT header information
В этом случае для удаления разделов достаточно воспользоваться утилитой fdisk (в случае, если используется таблица MBR) или выполнить команду:
dd if=/dev/zero of=/dev/hd0 bs=1024 count=64
Создание новой таблицы разделов в формате GPT (вывод команд ориентировочный):
gdisk /dev/hd0 create gdisk /dev/hd0 show Dev Num Start End Size (Mb) Type Min Sector: 2048 Max Sector: 234441614
Создание загрузочного EFI раздела размером, например, 198 Mb (для файловой системы FAT32):
gdisk /dev/hd0 add -n1 -c 2048,407680 -t efi
Создание раздела для файловой системы Power-Safe для последующей установки ОС:
gdisk /dev/hd0 add -n2 -c 407681,134441614 -t qnx6
Далее следует перечитать таблицу разделов, чтобы отразились только что созданные разделы:
mount -e /dev/hd0 ls /dev/hd0.* /dev/hd0.072f5f61-5287-c84f-8012-d62ff149a254 /dev/hd0.099bbac7-0434-2949-b52d-ac6e2b6ad390
В данный момент нет возможность определить какому разделу соответствует UUID. При форматировании следует обращать внимание на размеры разделов:
gdisk /dev/hd0 show
Форматирование загрузочного и рабочего разделов операционной системы:
mkdosfs -F 32 -L BOOT -c 512 \ /dev/hd0.099bbac7-0434-2949-b52d-ac6e2b6ad390 Format complete: FAT32 (512-byte clusters), 199679 kB available. mkqnx6fs /dev/hd0.072f5f61-5287-c84f-8012-d62ff149a254 Format fs-qnx6: 67016948 blocks, 1047144 inodes, 16 groups
Установите первичный загрузчик ipl-uefi в загрузочный EFI раздел диска, примонтировав соответствующий раздел:
mount -t dos /dev/hd0.099bbac7-0434-2949-b52d-ac6e2b6ad390 /uefi-boot mkdir /uefi-boot/efi mkdir /uefi-boot/efi/boot cp -V ${KPDA_TARGET}/x86/boot/sys/ipl-uefi /uefi-boot/efi/boot/ sync umount /uefi-boot
После этого следует установить в файловую систему Power-Safe операционную систему.
После завершения редактирования таблицы разделов можно приступать к подготовке собственно разделов файловой системы.
При использовании файловой системы Power-Safe (драйвер fs-qnx6.so) вторичный загрузчик осуществляет валидацию файловой системы и определяет самый новый из ее стабильных срезов ( snapshot). Затем он отображает список всех подходящих файлов каталога .boot в прокручивающемся списке, из которого пользователь может выбрать необходимый загружаемый образ.
Если каталог .boot содержит только один файл, то вторичный загрузка начинается немедленно; в противном случае загрузчик 3-4 секунды ожидает нажатие кнопки. Для перемещения между файлами используются стрелки вверх и вниз, выбор осуществляется нажатием клавиши «Ввод» (Enter). Для перехода в начало или конец списка так же можно использовать клавиши Home и End. На экране может отображать до 10 файлов; для просмотра остальных необходимо удерживать клавишу со стрелкой вниз или вверх.
Если пользователь не нажимает клавишу, то по истечению таймаута вторичный загрузчик продолжит работу, используя образ по умолчанию. Это файл, имеющий самое недавнее время модификации, в списке он всегда отображается первым. В общем случае это будет последний образ, скопированный в каталог .boot; для изменения образа по умолчанию можно использовать утилиту touch. Для определения образа по умолчанию можно выполнить команду:
ls -t /.boot | head -1
Вторичный загрузчик может быть обновлен без переформатирования раздела (т.е. без потери данных файловой системы) с помощью команды: mkqnx6fs -B.
Для загрузки могут использоваться только файловые системы «little-endian» (т.е. отформатированные на любом компьютере командой mkqnx6fs -el либо отформатированные на компьютере «little-endian» без указания порядка следования байт).
Вторичный загрузчик поддерживает только два уровня иерархии блоков файловой системы. Следовательно, при использовании 512-байтных блоков «область видимости» (cutover) составляет 128 Кбайт, поэтому файловая система, отформатированная командой mkqnx6fs -b 512 вероятнее всего не будет пригодной для загрузки. При использовании блоков размером 1 Кбайт (это значение по умолчанию) «область видимости» составляет 1 Гбайт.
Вторичный загрузчик может выдавать следующие сообщения об ошибках:
.boot пуст.
Инициализация и установка вторичного загрузчика для файловой системы QNX4 производится с помощью утилиты dinit:
dinit -h /dev/hd0t77
Вторичный загрузчик выводит следующее сообщение:
Hit Esc for .altboot
Если интервал ожидания истекает, то вторичный загрузчик загружает образ операционной системы из файла /.boot, а при нажатии клавиши Esc извлекает образ из файла /.altboot. В процессе считывания образа загрузчик печатает последовательность точек.
Если происходит ошибка, вторичный загрузчик выводит один из перечисленных далее символов и процесс загрузки останавливается:
Единственное различие между образами, которые устанавливаются по умолчанию, заключается в том, что образ /.boot осуществляет прямой доступ к памяти EIDE-контроллера, а образ /.altboot — нет.
В каталоге /boot/build/ находятся следующие файлы построения образа:
.boot (см. приложение); .altboot. Несмотря на то, что файлы /.boot и /.altboot можно изменять, а также копировать в них содержимое других файлов, их нельзя переименовывать и удалять, а также удалять ссылки на них. Например, следующие команды не сработают:
mv /.altboot oldaltboot mv newboot /.altboot
А эти команды выполнятся успешно:
cp /.altboot oldaltboot cp newboot /.altboot
| При модификации загрузочного образа рекомендуется скопировать работоспособный образ из файла /.boot в файл /.altboot, а затем поместить новый образ в файл /.boot. В случае ошибки это даст возможность нажать клавишу Esc при следующей загрузке и воспользоваться работоспособным загрузочным образом для восстановления. |
Файл построения образа по умолчанию .boot, qnxbasedma.build включает в себя следующие строки:
[+script] startup-script = { # To save memory make everyone use the libc in the boot image! # For speed (less symbolic lookups) we point to libc.so.2 instead # of libc.so procmgr symlink ../../proc/boot/libc.so.2 /usr/lib/ldqnx.so.2 # Default user programs to priority 10, other scheduler (pri=10o) # Tell "diskboot" this is a hard disk boot (-b1) # Tell "diskboot" to use DMA on IDE drives (-D1) # Start 4 text consoles buy passing "-n4" to "devc-con" (-o) # By adding "-e" Linux ext2 filesystem will be mounted as well. [pri=10o] PATH=/proc/boot diskboot -b1 -D1 -odevc-con,-n4 }
Этот сценарий запускает систему с помощью программы diskboot, которая предназначена для загрузки операционной системы ЗОСРВ «Нейтрино» на дисковых компьютерах. Полное содержимое файла qnxbasedma.build см. в приложении.
|
|
При запуске программа diskboot отображает следующее приглашение:
Press the space bar to input boot options... (Нажмите клавишу пробела, чтобы ввести параметры загрузки...)
Большая часть этих параметров предназначена для отладочных целей. Программа diskboot выполняет поиск раздела операционной системы ЗОСРВ «Нейтрино», чтобы смонтировать его, а затем запускает последовательность сценариев для инициализации системы (рис. 3).
Основным сценарием инициализации системы является /etc/system/sysinit. Локальные файлы инициализации обычно хранятся в каталоге /etc/rc.d. Чтобы запустить на узле дополнительные команды, например, для монтирования диска с файловой системой NFS, можно создать файл сценария с именем rc.local, сделать его исполняемым и поместить его в каталог /etc/rc.d. Более подробные сведения см. в описании файла rc.local далее в этой статье.
Программа diskboot выполняет следующие действия.
1, 4, 6, 11, 12, 14 — операционная система DOS; 131 — файловая система Ext2, если программе diskboot передан параметр -e; 177, 178, 179: файловая система Power-Safe — 177 и 178 указывают вторичные разделы; 77, 78, 79 — операционная система QNX4. Эти разделы монтируются в каталоги /fs/cdx (для CD-ROM) и /fs/hdx-тип-y, где x является номером диска (например, /fs/cd0, /fs/hd1), а y — увеличивающийся параметр, который добавляется для уникальности. Например, вторым DOS-разделом на жестком диске 1 будет /fs/hd1-dos-2.
В нарушение этого правила один раздел операционной системы QNX4 по умолчанию монтируется в каталог /. Это можно проверить, просмотрев содержимое файла .diskroot на каждом разделе QNX4. Если существует только один раздел QNX4, в файле .diskroot которого определена точка монтирования /, этот раздел демонтируется из каталога /fs/hdx-тип-y, а затем монтируется в каталог /. Если имеется несколько таких разделов, программа diskboot предлагает выбрать один из них.
Файл .diskroot, как правило, пуст, но может содержать команды. Более подробные сведения см. далее в этой статье.
/etc/system/sysinit.
Программа diskboot использует файл .diskroot для того, чтобы определить, какой раздел с операционной системой QNX4 смонтировать в каталог /. Файл .diskroot может являться:
.diskroot имеет нулевую длину, что означает запрос на точку монтирования /; /home
Строка не должна начинаться со знака номера (#) или содержать знак равенства (=). Программа diskboot игнорирует пробельные символы в начале и в конце строки;
метка = значение
Программа diskboot игнорирует любые пробельные символы в начале и в конце строки, а также до и после знака равенства.
Распознаются следующие метки:
Файл /etc/system/sysinit является сценарием, который запускает основные системные службы. Для того чтобы отредактировать этот файл, необходимо войти в систему как пользователь root.
| Перед тем как редактировать сценарий sysinit, рекомендуется создать резервную копию его последней работоспособной версии. Следует помнить, что сценарии, которые написаны пользователем, необходимо делать исполняемыми перед использованием (см. chmod). |
Сценарий sysinit выполняет следующие действия.
sysinit запускает сценарий /etc/rc.d/rc.setup-once, который создает различные каталоги и своп-файлы.
_CS_TIMEZONE значение, которое хранится в файле /etc/TIMEZONE. Если этот файл не существует, сценарий sysinit задает часовой пояс UTC (Universal Time Coordinated — всеобщее скоординированное время, ранее называвшееся Greenwich Mean Time — время по Гринвичу). Более подробную информацию см. в Задание часового пояса.
/etc/rc.d/rc.rtc существует и является исполняемым, сценарий sysinit запускает его для настройки часов реального времени.
Рекомендуется устанавливать аппаратные часы по часовому поясу UTC, а временную зону задавать с помощью конфигурационной строки _CS_TIMEZONE или переменной окружения TZ. Система отображает и рассчитывает местное время, а также автоматически определяет начало и окончание летнего и зимнего времени.
Этот подход к управлению системным временем дает возможность пользователям, которые находятся в разных часовых поясах и подключаются к одному компьютеру, видеть правильное местное время. Кроме того, настройка аппаратных часов на время UTC удобна при передаче данных между разными часовыми поясами. К данным добавляется штамп времени по часовому поясу UTC, и все компьютеры с легкостью сравнивают штампы времени, которые установлены в разных часовых поясах.
Некоторые операционные системы, например Windows, устанавливают местное время на аппаратных часах. Если операционные системы Windows и ЗОСРВ «Нейтрино» устанавливаются на один компьютер, то следует задать на аппаратных часах местное время, выполнив следующую команду от имени пользователя root и поместив ее в файл /etc/rc.d/rc.rtc:
rtc -l hw
В оконном окружении Photon достаточно снять флажок "The hardware clock uses UTC/GMT" в программе phlocale. В этом случае утилита phlocale создаст файл rc.rtc, который содержит указанную выше команду.
sysinit записывает в переменную окружения HOSTNAME имя хоста системы. Сценарий sysinit определяет это имя с помощью команды hostname или считывает его из файла /etc/HOSTNAME, если команда hostname не срабатывает; | Имя хоста может состоять только из букв, цифр и символов дефиса, а также не должно начинаться и заканчиваться символом дефиса. Более подробные сведения см. в RFC 952. |
sysinit запускает сценарий /etc/rc.d/rc.devices для распознавания устройств системы (см. раздел "Распознавание устройств" далее в этой статье). В зависимости от обнаруженных устройств этот сценарий запускает драйвер io-pkt-* и другие различные драйверы. /etc/system/config/useqnet существует и драйвер io-pkt-* работает, сценарий sysinit инициализирует собственную сеть операционной системы ЗОСРВ «Нейтрино».
sysinit запускает сценарий инициализации системы /etc/rc.d/rc.sysinit (см. далее в этой статье).
sysinit пытается запустить утилиту sh или fesh (если sh не срабатывает), чтобы обеспечить работу, как минимум, командного интерпретатора при отказе остальных компонентов системы.
Для обнаружения всех известных аппаратных устройств компьютера и запуска соответствующих драйверов в операционной системе ЗОСРВ «Нейтрино» используется программа распознавания устройств (device enumerator) — администратор enum-devices. Он вызывается сценарием /etc/rc.d/rc.devices, который запускается программой /etc/system/sysinit.
Чтобы определить действия, которые должны быть выполнены при обнаружении конкретных аппаратных устройств, администратор enum-devices использует набор конфигурационных файлов. После считывания конфигурационных файлов утилита enum-devices вызывает различные программы распознавания, чтобы определить, какие устройства имеются в системе.
Затем идентификаторы устройств сравниваются с идентификаторами, которые указаны в конфигурационных файлах. Если устройство обнаруживается, то исполняются операторы, которые связаны с этим устройством. Конфигурационные файлы программ распознавания расположены в каталоге /etc/system/enum.
Далее приведен пример кода конфигурационного файла:
device(pci, ven=2222, dev=1111) uniq(sernum, devc-ser, 1) driver(devc-ser8250, "-u$(sernum) $(ioport1),$(irq)")
Этот код указывает программе распознавания выполнить следующие действия при обнаружении устройства 1111 производителя 2222:
Чтобы распознать новое оборудование или задать дополнительные параметры, можно расширить набор конфигурационных файлов следующими способами:
Перед обработкой программа распознавания считывает и объединяет содержимое всех конфигурационных файлов, которые расположены в выбранном каталоге.
Более подробные сведения о других командно-строковых параметрах и описание синтаксиса конфигурационных файлов см. в enum-devices.
Производитель комплектного оборудования, который написал собственные драйверы для устройств, может создать каталог oem в каталоге /etc/system/enum для хранения конфигурационных файлов устройств.
Если необходимо настроить устройства или параметры, которые специфичны для конкретной системной конфигурации, следует создать файл overrides в каталоге /etc/system/enum. Программа распознавания включает этот файл в множество конфигурационных файлов последним и добавляет определения, которые содержатся в нем, в набор, с которым работает администратор enum-devices. Если файл overrides содержит определение, которое имеется в ранее включенном файле, то используется более позднее определение. Рассмотрим примеры.
/etc/system/enum/overrides и добавить в него запись
device(...) для этого устройства: device(pci, ven=1234, dev=2000) device(pci, ven=1234, dev=2001) requires( $(IONET CMD), ) uniq(netnum, devn-en, 0) mount(-Tio-net /lib/dll/devn-pcnet.so, "/dev/io-net/en$(netnum)") device(pci, ven=1234, dev=2002) device(pci, ven=1234, dev=2003)
Если программа распознавания обнаруживает устройства 2000 и 2001 производителя 1234, то первый фрагмент этого кода задает следующие действия:
IONET_CMD представляет собой макрос, который определен в файле /etc/system/enum/include/net, и задает командную строку драйвера io-pkt-* по умолчанию; 0; | При добавлении записей device, которые отключают распознавание устройств, следует убедиться в том, что после этих записей отсутствуют какие-либо операторы действий. Группы операторов действий, которые следуют за одной или несколькими записями устройств, применяются к этим устройствам. Записи устройств, распознавание которых требуется отключить, следует помещать в конец конфигурационного файла overrides. |
/etc/system/enum/include/net. По умолчанию она выглядит следующим образом:
io-pkt-v4-hc -ptcpip
Если требуется включить протокол IPSec, в файл overrides нужно добавить следующий код:
all set(IOPKT_CMD, io-pkt-v4-hc -ptcpip ipsec)
Для того чтобы точнее настроить программы распознавания в соответствии с конфигурацией системы, можно создать каталог /etc/host_cfg/$HOSTNAME/system/enum. Если эта структура каталогов существует, сценарий rc.devices указывает программе распознавания считывать конфигурационные файлы из нее, а не из каталога /etc/system/enum.
| Даже если каталог /etc/host_cfg/$HOSTNAME/system/enum существует, программа распознавания выполняет поиск каталога oem и файла overrides в каталоге /etc/system/enum. |
/etc/host_cfg/$HOSTNAME/system/enum можно легко сконфигурировать следующим образом: скопировать каталог /etc/system/enum (в том числе все его подкаталоги) в каталог /etc/host_cfg/$HOSTNAME/system, а затем приступить к настройке.
Сценарий /etc/system/sysinit запускает сценарий /etc/rc.d/rc.sysinit для локальной инициализации системы (рис. 4).
Сценарий rc.sysinit выполняет следующие действия.
/var/dumps существует, то сценарий rc.sysinit запускает утилиту dumper для записи дампов процессов, которые завершились ненормально, в каталог /var/dumps. /etc/host_cfg/$HOSTNAME/rc.d/rc.local существует и является исполняемым, то сценарий rc.sysinit запускает его. В противном случае сценарий rc.sysinit запускает файл /etc/rc.d/rc.local, если он существует и является исполняемым. У этого файла не существует версии по умолчанию, поэтому при необходимости ее нужно создать вручную. Более подробные сведения см. в подразделе "Файл rc.local" далее в этой статье. rc.sysinit запускает программу tinit. По умолчанию система запускает оконное окружение Photon, но в случае если создан файл /etc/system/config/nophoton, сценарий rc.sysinit указывает утилите tinit использовать текстовый режим. Более подробные сведения см. в разделе "Утилита tinit" далее в этой статье.
Как описано ранее, сценарий rc.sysinit запускает файл /etc/host_cfg/$HOSTNAME/rc.d/rc.local или /etc/rc.d/rc.local, если он существует и является исполняемым.
С помощью файла rc.local можно конфигурировать запуск системы:
rc.local также позволяет уничтожать работающие процессы с помощью утилиты slay и перезапускать их с другими параметрами, однако такой подход является громоздким. Вместо него для запуска процессов с требуемыми параметрами следует изменить распознавание устройств. Более подробные сведения см. в разделе "Распознавание устройств" ранее в этой статье.
С помощью файла rc.local пользователь может, к примеру:
/usr/photon/bin/Photon -l '/usr/photon/bin/phlogin -O -Uпользователь:пароль'
Следует иметь в виду, что пароль необходимо поместить в файл rc.local в виде простого текста, однако нужно сказать, что пользователь, который желает пропустить приглашение для входа в систему, вероятно, не заботится о ее безопасности.
Параметр -O утилиты phlogin2 переводит систему в текстовый режим после завершения сеанса оконного окружения Photon. При отсутствии параметра -O нажатие комбинации клавиш <Ctrl> + <Shift> + <Alt> + <Backspace> приводит к повторному входу в систему.
В качестве альтернативы можно задать запуск оконного окружения Photon командой ph в файле .profile, а затем добавить в файл rc.local следующую команду:
login -f имя_пользователя
Более подробные сведения см. в описании login.
Не следует задавать переменные окружения в сценарии rc.local, поскольку после его выполнения запускается другой командный интерпретатор, и к моменту, когда пользователю предлагается войти в систему, все переменные окружения, которые определены в файле rc.local, перестают существовать.
| После создания файла rc.local следует с помощью команды chmod +x rc.local установить его атрибут разрешения на исполнение (executable bit). |
Программа tinit инициализирует терминал следующим образом:
/etc/config/ttys и запускает утилиту login или командные интерпретаторы в соответствии с его содержанием.
В процессе начальной загрузки ЗОСРВ «Нейтрино» можно динамически добавлять драйверы блочного ввода/вывода (т.е. драйверы диска), что дает возможность загружаться в системе с новыми контроллерами.
Под обновлением драйвера понимается обновление собственно драйвера (только devb-*) и добавление простого конфигурационного файла. Конфигурационный файл состоит из строк обычного текста (с окончаниями строк в стиле DOS или UNIX) следующего формата:
drvr_name|type|timeout|add_args
Первые три поля являются обязательными. Поля имеют следующее назначение:
Конфигурационному файлу может быть дано имя drivers.cfg, и вы должны добавить обновления на физический носитель, в настоящее время это CD-ROM или USB-диск. В процессе начальной загрузки вначале просматривается корневая область файловой системы, а затем каталог с именем qnxdrvr. Это может помочь уменьшению перегруженности корневой зоны файловой системы.
Исходной может быть любая из поддерживаемых файловых систем. Известно, что работают такие файловые системы:
t7) и QNX4 (раздел t79) на USB-диске. Применить обновленные версии драйверов можно, нажав клавишу <Пробел> в процессе загрузки, а затем клавишу <F2>. После этого завершится этап начальной загрузки в систему стандартных блочных драйверов, и в исходную файловую систему могут быть загружены обновления. Вам будет выдана подсказка о выборе файловой системы и будет предложено вставить носитель с обновлениями.
| Если необходимо повторно просканировать разделы (например, для поиска USB-диска, который вы вставили после начала процесса загрузки), нажмите клавишу <F12>. |
Когда завершится копирование файлов, появится подсказка о необходимости повторной установки инсталляционного компакт-диска (если он используется). Тогда произойдет перезапуск блочных драйверов.
Использование такого механизма дает возможность обновить существующие драйверы или просто модифицировать их аргументы (например, спецификацию PCI ID).
Если идет процесс инсталляции, то программа производит копирование обновленных драйверов в каталог /sbin, а конфигурационного файла — в каталог /boot/sys. Одновременно производится также копирование стандартных файлов компоновки в каталог /boot/build (кроме файлов, имеющих отношение к многоядерности), файлам присваиваются имена qnxbase-drvrup.build и qnxbasedma-drvrup.build. Эти файлы затем используются для создания новых файлов образа с именами qnxbase-drvrup.ifs и qnxbasedma-drvrup.ifs в папке /boot/fs. DMA-версия нового файла копируется в каталог /.boot, не-DMA-версия — в каталог /.altboot.
| Программа инсталляции не выполняет перекомпоновку многоядерных (SMP) образов. |
Рассмотрим некоторые проблемы, связанные с конфигурированием запуска системы.
rc.local, не запускаются. rc.local является исполняемым, и при необходимости сделать его исполняемым с помощью команды chmod: chmod +x /etc/rc.d/rc.local
/etc/rc.d/rc.local. rc.local испорчен, и теперь я не могу загрузить систему. rc.local <Пробел>, а затем клавишу <F5>, запустится отладочная оболочка. Когда вы войдете в отладочную оболочку ( fesh), введите команду exit, а затем дождитесь второй подсказки от оболочки. Далее введите команду: rc.local или убрать его с пути загрузки, чтобы загрузка шла без его участия:
Предыдущий раздел: перейти