Вопросы и ответы (глава 10)

Как установить удаленную загрузку?

Для обеспечения удаленной загрузки необходимо в сетевой адаптер установить микросхему Boot ROM и создать загрузочный образ на файл-сервере.
Загрузочный образ в Novell NetWare представляет собой файл NET$DOS.SYS, созданный утилитой DOSGEN.EXE, находящийся в каталоге SYS:SYSTEM для доступного файл-сервера. Он содержит элементы загрузочной дискеты: загрузчик, системные файлы DOS, COMMAND.COM, CONFIG.SYS, AUTOEXEC.BAT и все драйверы и программы, необходимые для загрузки и настройки DOS и клиентской оболочки, обеспечивающей возможность регистрации пользователя в сети.

Загрузочная дискета стандартного формата (5": 160 Кбайт, 360 Кбайт, 1.2 Мбайт или 3.5": 720 Кбайт, 1.44 Мбайт, 2.88 Мбайт) подготавливается и отлаживается на станции-прототипе с загрузочным дисководом обычными средствами DOS, с целью экономии дискового пространства сервера выбирается по возможности меньший формат. Новые версии DOSGEN (3.12+) поддерживают структуру вложенных каталогов загрузочной дискеты.

Утилита DOSGEN из поставки NetWare или IMAGEGEN из BootWare запускается с необязательными параметрами [d:] [filename], задающими имя загрузочного диска (даже жесткого) и файла-образа, по умолчанию А: и NET$DOS.SYS соответственно.

Файл-образ помещается в каталог SYS:LOGIN и ему присваивается атрибут разделяемости S для обеспечения возможности одновременной удаленной загрузки нескольких станций. После этого сервер готов к обслуживанию запросов удаленной загрузки.

На станции с установленным удаленным загрузчиком при неготовности дисковода A: начальная загрузка производится либо с жесткого диска (если он есть и имеет активный раздел), либо через Boot ROM; выбор загрузочного устройства производится с консоли. Попытку загрузки с жесткого диска можно блокировать снятием признака активности (загружаемости) его разделов.

Почему при переходе на MS-DOS 5.0 станция перестает загружаться по сети?

Многие старые версии Boot ROM при использовании DOS 5.0 и старше требуют коррекции образа утилитой RPLFIX, без коррекции в процессе загрузки произойдет зависание. Новые версии, имеющие автоматическую настройку на версию DOS, наоборот, зависают на скорректированных образах. Для них уже скорректированный образ можно восстановить утилитой UNRPLFIX из BootWare.

Как происходит удаленная загрузка?

Удаленный загрузчик симулирует загрузку DOS с диска A:, подставляя вместо данных из секторов реального диска данные, полученные по сети из открытого файла-образа - пока единственного доступного файла на сервере. Таким образом загрузчик Boot загружает системные файлы DOS и передает им управление, далее происходит загрузка с отработкой CONFIG.SYS из образа. В процессе отработки .BAT-файлов (AUTOEXEC или других) загружаются необходимые драйверы сетевого адаптера и клиент сети (NETX или VLM). Успешная загрузка клиента приводит к важному событию: появляется доступный сетевой диск (обычно F:), отображающий каталог SYS:LOGIN сервера. Одновременно закрывается файл-образ и восстанавливается отображение диска A: на реальный привод, ранее перехваченное удаленным загрузчиком, загрузчик освобождает занимаемую память. Кроме того, NETX (или VLM) передает управление в точку, следующую за строкой его запуска в .BAT-файле с тем же именем, из которого он был запущен, но расположенного в директории SYS:LOGIN. Это событие называют NETX (или VLM) Transfer Point - точка передачи управления.

Все программы, загруженные до точки передачи управления, "ощущают" себя запущенными с логического диска A:, и DOS будет пытаться загружать COMMAND.COM с диска A:. По этой причине командный процессор (COMMAND.COM) должен переопределяться на доступный сетевой диск командой

COMSPEC = pathname

в процедуре регистрации LOGIN или более надежным способом -

SET COMSPEC = pathname

в .BAT-файле, вызываемом LOGIN-командой

EXIT "fname.BAT".

Программы, чувствительные к маршруту запуска, следует по возможности загружать после NETX (VLM) из каталога SYS:LOGIN, уже доступного по чтению, или после LOGIN с сетевых дисков, спланированных во время или после регистрации пользователя в сети. Возможно и применение DOS-команды SUBST для подмены имени диска.
При использовании EMM386 он должен загружаться из CONFIG.SYS с дополнительными параметрами вида

DEVICE = EMM386.EXE X = start, end Y= Path\EMM386.EXE

где start,end - граничные параграфы памяти адаптера (см.4.4.), Path - полный путь к файлу EMM386.EXE на сетевом диске. Отсутствие параметров X и Y может приводить к зависанию во время запуска EMM386 и ошибке "Invalid path for EMM386" при запуске Windows в расширенном режиме соответственно.

С чем связано сообщение "Batch File Missing" при удаленной загрузке?

Эта неприятность связана с эффектом подмены диска в точке передачи управления. Для корректного исполнения .BAT-файла, из которого запускался NETX или VLM, его копия с тем же именем должна находиться в каталоге SYS:LOGIN, который станет текущим после исполнения NETX (VLM). Если процедура регистрации меняет назначения текущего каталога, то еще одна копия .BAT-файла должна присутствовать в этом новом текущем каталоге. Строго говоря, эти .BAT-файлы должны совпадать только по количествам символов до точки передачи управления, что можно использовать для оперативной смены процедуры загрузки без изменения образа.

Если последней командой .BAT-файла является команда LOGIN, символы CR, LF (0Dh, 0Ah), стоящие в конце этой строки, должны быть удалены редактором или утилитой BATCRLF, входящей в комплект BootWare.

Стандартный способ внесения изменений в загрузочный образ через исправления на дискете и с помощью DOSGEN неудобен и обязательно требует наличия станции с дисководом. Более удобный способ - применение утилиты MAPGEN из BootWare, позволяющей отображать ранее созданный файл-образ на локальный диск A: или B: рабочей станции, возможно и реально отсутствующий. Размер свободной оперативной памяти этой станции, включая XMS и EMS, должен быть достаточным для размещения в нем образа диска и загрузки текстового редактора, если есть необходимость редактирования CONFIG.SYS или .BAT-файлов образа. Работа с образом не отличается от работы с реальным диском, за исключением невозможности обновления версии DOS. Результаты работы сохраняются в файле-образе, RPLFIX не используется.

Как быть, если на разных станциях требуются разные загрузочные образы?

При необходимости загрузки на разных станциях систем, различающихся до точки передачи управления (например, использующих различные файлы CONFIG.SYS или сетевые адаптеры с различной аппаратной конфигурацией), в SYS:LOGIN создается необходимое множество загрузочных образов с различными именами и текстовый файл BOOTCONF.SYS, связывающий файлы-образы с сетевыми адресами адаптеров. В начале загрузки станция запрашивает файл BOOTCONF.SYS и берет из него имя соответствующего образа. При отсутствии BOOTCONF.SYS делается запрос на файл NET$DOS.SYS или IBM$DOS.SYS. При невозможности получения требуемого образа загрузка прерывается с сообщением Error opening image file.

Некоторые версии загрузчиков до запроса NET$DOS.SYS ищут файл со своим специфическим именем, соответствующим типу адаптера.
При различиях в файлах AUTOEXEC.BAT загрузочных образов клиентские оболочки должны запускаться из .BAT-файлов, имеющих уникальные имена и запускаемых из AUTOEXEC.BAT. Копии этих файлов должны присутствовать в SYS:LOGIN и новых текущих сетевых директориях.

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

Файл BOOTCONF.SYS для каждой удаленно загружаемой станции содержит строку вида 0xnet_num,addr = fname.ext [comment], где net_num и addr - шестнадцатеричный номер сети и MAC-адрес адаптера, fname.ext - имя файла, хранящего образ загрузки для данной станции, comment - необязательный комментарий. В номере сети начальные нули могут быть опущены.

Необязательный загружаемый модуль RPL.NLM (NetWare 3.11+) расширяет возможности BOOTCONF.SYS, допуская использование в нем метасимволов "?" и "*" для задания группы адресов, указание нескольких файлов-образов для выбора загрузочного сценария пользователем, замены всех появлений в файле-образе ASCII строки-1 на строку-2 перед посылкой их на станцию для дополнительных изменений исполнения образа.

Почему при установке нового сервера удаленная загрузка стала нестабильной?

Скорее всего, на новом сервере не установлены все файлы, необходимые для удаленной загрузки (образы и, если их много - BOOTCONF.SYS).

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

Существенно облегчить работу администратора NetWare позволяет использование средств BootWare for NetWare: BootWare Manager - программа просмотра, диагностики и модификации загрузочных последовательностей станций, работающая в среде Windows, и серверный модуль MSD.NLM (Multi-Server Director), позволяющий не копировать загрузочные файлы на все серверы многосерверной сети.

MSD.NLM запускается на одном из серверов NetWare 3.x или 4.x и поддерживает список до 2048 станций, определяя для каждой местонахождение ее загрузочных файлов. Список представляет собой файл BOOTCONF.SYS с расширенным синтаксисом, включающим имя файл-сервера для конкретной станции. Для станций, не входящих в список, можно создать дежурные загрузочные образы, выбираемые MSD по типу адаптера станции, запрашивающей загрузку. Для ускорения поиска MSD работает с копией BOOTCONF.SYS в памяти сервера. На консоль MSD выводится детальная информация по загрузке станций.

MSDEDIT.EXE - специализированный редактор файла BOOTCONF.SYS в среде DOS, дублирующий эту функцию программы BootWare Manager.

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

Удаленный загрузчик не находит сервера с файлом-образом, хотя при загрузке клиента с дискеты нет проблем. В чем дело?

Очевидно, дело в используемых типах фреймов. Различные версии BootROM используют типы фреймов 802.3, 802.2 и Ethernet_II, некоторые из них поддерживают любой тип, некоторые требуют предварительного указания типа, некоторые поддерживают только один фиксированный тип. Используемый тип фрейма должен поддерживаться файл-сервером и быть связанным с протоколом IPX в этой сети.

Первый из указанных фреймов в секции Link Driver файла NET.CFG, являющийся типом по умолчанию и используемый RPLODI, может отличаться от используемого удаленным загрузчиком. Если в секции указано несколько типов фреймов, а IPX связан не с первым, то в NET.CFG необходима привязка IPX к конкретному типу фрейма (например, 802.2) строкой

Protocol IPX E0 Ethernet_802.2

Какие серверы допускают удаленную загрузку станций по протоколу Novell RPL?

Кроме серверов NetWare 3.x - 4.x этот протокол поддерживает и сервер Personal NetWare . Для этого на нем создается сетевой каталог с именем LOGIN, в который помещаются файлы, необходимые для загрузки: NET$DOS.SYS и AUTOEXEC.BAT. Из него же запускается NEARSERV.EXE - резидентная программа, обеспечивающая ответы на запрос ближайшего сервера и удаленную загрузку. При необходимости использования множества образов создается файл BOOTCONF.SYS. Для протокола RPL используется резидент RPL.COM и соответствующие .RPL-файлы.

Если в сети присутствуют серверы "больших" NetWare, удаленная загрузка из NetWare Lite работать не будет.

При использовании пакетных драйверов, загружаемых перед протоколом IPX, удаленная загрузка зависает. Как быть?

Эти проблемы удаленной загрузки обычно возникают из-за перехвата этими драйверами управления адаптером и разрушения принятого пакета при инициализации до завершения загрузки. Один путь решения - создание при загрузке станции RAM-диска, копирование на него пакетных драйверов и IPX и исполнение их уже без использования образа. Другой путь - задержка инициализации драйверов до загрузки IPX, возможная в некоторых версиях драйверов.

При использовании сетевой карты EMM386 работает с загадочными ошибками, а при попытке удаленной загрузки станции по сети происходит зависание в самом начале процесса, в чем дело?

Эта ситуация возникает, когда при сканировании UMA EMM386 обнаруживает RAM адаптера и пытается использовать ее для своих нужд. При удаленной загрузке сканирование сразу разрушает принятый пакет, необходимый для загрузки ОС, и компьютер зависает. Без удаленной загрузки разрушение данных во владениях EMM произойдет в произвольный момент, когда придет пакет, адресованный данному адаптеру, - поэтому такая ошибка локализуется с трудом. Выход из положения - исключить область RAM адаптера из использования EMM386 заданием параметра "X=Start,End" в командной строке запуска, где Start и End - адреса начального и конечного параграфов области RAM адаптера (четырехзначные шестнадцатеричные числа).

Как сконфигурировать Boot ROM (Adapter ROM)?

Разрешение работы ROM задается при необходимости, размер указывается в соответствии с применяемой микросхемой, базовый адрес выбирается по тем же соображениям, что и для Adapter RAM. Использование теневой памяти (Shadow ROM) для ускорения работы смысла не имеет, поскольку программный код ROM адаптера за редкими исключениями исполняется однократно только в процессе загрузки системы.

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

Почему строка процедуры регистрации разбивается на кусочки?

Символ "\" в процедуре регистрации является префиксом управляющей комбинации (см. табл. 9.1), вместо него используется символ "/". Если об этом забыть, то строка

EXIT "C:\RUNSTART.BAT"

будет трактоваться как две команды

C:
UNSTART.BAT

на что наверняка последует ответ системы

Bad command or filename.

Глава 11 | Вопросы и ответы (глава 11) | Содержание