Если ваша рабочая станция не загружается после выполнения инструкций, указанных в предыдущих главах, вам необходимо приступить к устранению проблем установки.
Первым делом Вы должны выяснить насколько далеко проходит нормальный процесс загрузки.
При загрузке с дискеты Вы должны увидеть что-то похожее на это:
loaded ROM segment 0x0800 length 0x4000 reloc 0x9400 Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI] Found AMD Lance/PCI at 0x1000, ROM address 0x0000 Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01 Searching for server (DHCP)... <sleep> |
Приведенный выше пример показывает что Вы должны увидеть на экране при загрузке с дискеты. Если Вам не удается увидеть эти сообщения, указывающие на то, что Etherboot стартовал, то, возможно, у Вас либо сбойная дискета, либо образ Etherboot был записан на дискету некорректно.
Если сообщения выглядят наподобие приведенных ниже, возможно, сгенерированный образ Etherboot не подходит к Вашей сетевой плате.
ROM segment 0x0800 length 0x8000 reloc 0x9400 Etherboot 5.0.2 (GPL) Tagged ELF for [Tulip] Probing...[Tulip]No adapter found <sleep> <abort> |
Если процесс загрузки все-таки доходит до определения сетевой платы и отображается корректный MAC-адрес, возможно, дискета в порядке.
Когда сетевая плата инициализируется, она посылает в локальную сеть широковещательный DHCP-запрос, пытаясь найти DHCP-сервер.
После получения правильного ответа от DHCP-сервера, рабочая станция конфигурирует сетевую плату. По отображаемому на экране IP-адресу можно определить правильно ли прошел данный этап. Вот как примерно это должно выглядеть:
ROM segment 0x0800 length 0x4000 reloc 0x9400 Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI] Found AMD Lance/PCI at 0x1000, ROM address 0x0000 Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01 Searching for server (DHCP)... <sleep> Me: 192.168.0.1, Server: 192.168.0.254, Gateway 192.168.0.254 |
DHCP работает правильно, если видна строка, начинающаяся на 'Me:', после чего должен следовать IP-адрес. Если это так, можно приступить к проверке работы TFTP.
Если вместо этого Вы видите следующее сообщение, за которым идут много <sleep>-сообщений, то в чём-то проблема. Однако, появление одного-двух <sleep>-сообщений до того как DHCP-сервер ответит, считается допустимым.
Searching for server (DHCP)... |
Выяснение причины неполадок иногда может быть сложным, но вот какие вещи можно посмотреть.
Подключена ли физически рабочая станция к той же самой сети, что и сервер?
Удостоверьтесь, что при включенной рабочей станции индикаторы связи горят.
Если рабочая станция и сервер соединяются непосредственно, без участия концентратора или коммутатора, убедитесь, что используется перекрёстный кабель (cross-over cable), а, в случае соединения через концентратор или коммутатор, - прямой кабель (straight-thru cable), как между рабочей станцией и концентратором (например), так и между концентратором и сервером.
Необходимо определить запущен ли на сервере демон dhcpd. Ответ можно получить разными способами.
Обычно dhcpd выполняется в фоне, ожидая датаграмм на UDP-порту 67. Попробуйте команду netstat, чтобы узнать ожидает ли хоть что-нибудь на этом порту датаграммы:
netstat -an | grep ":67 " |
Должно получиться наподобие следующего:
udp 0 0 0.0.0.0:67 0.0.0.0:* |
Здесь четвертая колонка содержит IP-адрес и порт, отделенные друг от друга двоеточием (':'). Нулевой адрес ('0.0.0.0') указывает на то, что ожидание производится на всех интерфейсах. Т.е., например, у Вас могут быть eth0 и eth1 интерфейсы, и dhcpd будет ожидать датаграммы на обоих.
Поскольку netstat не показывает что именно ожидает на порту 67, то это может быть и не dhcpd. Это может оказаться демон bootpd, хотя это маловероятно, поскольку bootp в большинство дистрибутивов Linux он больше не включается.
Чтобы удостовериться в том, что это работает именно dhcpd, попробуйте команду ps.
ps aux | grep dhcpd |
Вы должны увидеть что-то похожее на следующее:
root 23814 0.0 0.3 1676 820 ? S 15:13 0:00 /usr/sbin/dhcpd root 23834 0.0 0.2 1552 600 pts/0 S 15:52 0:00 grep dhcp |
Здесь первая строка показывает, что dhcpd запущен. Вторая показывает просто нашу команду grep.
Если строк, указывающих на то, что dhcpd запущен, не видно, или (!!! ЗДЕСЬ ПРОПУСК В ОРИГИНАЛЬНОМ ТЕКСТЕ!!!)
Содержит ли файл /etc/dhcpd.conf вхождения для нашей рабочей станции?
Вы должны перепроверить настройку 'fixed-address' в конфигурационном файле чтобы убедиться, что она в точности соответствует сетевой плате рабочей станции.
Посмотрите что покажет следующая команда:
ipchains -L -v |
Дело не в ipchains, если вывод подобен следующему:
Chain input (policy ACCEPT: 229714 packets, 115477216 bytes): Chain forward (policy ACCEPT: 10 packets, 1794 bytes): Chain output (policy ACCEPT: 188978 packets, 66087385 bytes): |
Посмотрите что покажет следующая команда:
iptables -L -v |
Дело не в iptables, если вывод подобен следующему:
Chain INPUT (policy ACCEPT 18148 packets, 2623K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 17721 packets, 2732K bytes) pkts bytes target prot opt in out source destination |
С помощью следующей команды проследите изменение журнала /var/log/messages во время загрузки рабочей станции:
tail -f /var/log/messages |
Эта команда будет показывать все новые строки, записываемые в журнал. server dhcpd:
server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0 server dhcpd: no free leases on subnet WORKSTATIONS server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0 server dhcpd: no free leases on subnet WORKSTATIONS |
Сообщения, подобные вышеуказанным, говорящие "нет свободной емкости распределения", показывают, что dhcpd запущен, но не располагает никакой информацией о рабочей станции, запрашивающей IP-адрес.
Etherboot использует TFTP для загрузки с сервера ядра Linux. Это довольно простой протокол, но иногда возникают проблемы при попытке заставить его работать.
Следующее сообщение:
Loading 192.168.0.254:/lts/vmlinuz-2.4.9-ltsp-5 | |
с последним символом в строке ('|'), быстро меняющимся между '|', '\', '-' и '/', и выглядящим как крутящаяся палочка, показывает на то, что ядро загружается. Обычно это означает, что TFTP работает правильно.
Если же палочка не крутится, то есть проблема. Возможны, в частности, следующие проблемы:
В системах Redhat 7.1, tftp запускается посредством суперсервера xinetd. Существует стартовый скрипт /etc/xinetd.d/tftp, который содержит информацию для запуска tftpd
Ядро должно находится в доступном для демона tftpd месте. Если при запуске tftpd была задана опция '-s', то для какой бы то ни было рабочей станции путь до ядра должен быть относителен пути /tftpboot. Так, если параметр filename в файле /etc/dhcpd.conf задан как /lts/vmlinuz.tulip, то полный путь до файла образа ядра на самом деле таков: /tftpboot/lts/vmlinuz.tulip
Есть несколько причин, которые могут предотвратить монтаж корневой файловой системы. Включая следующие:
Сообщение об ошибке:
Kernel panic: No init found. Try passing init= option to kernel. |
как правило говорит, что либо сделана попытка монтажа неправильной директории в качестве корневой файловой системы, либо директория ltsroot пуста.
Сообщение об ошибке:
Root-NFS: Server returned error -13 while mounting /opt/ltsp/i386 |
указывает на то, что директория /tftpboot/lts/ltsroot не включена в файл /etc/exports.
Взгляните в журнал /var/log/messages - не встретятся ли какие-нибудь наводящие на мысль строки. Строка вида:
Jul 20 00:28:39 jamlap rpc.mountd: refused mount request from ws004
for /opt/ltsp/i386 (/): no export entry
|
подтвердит наши подозрения на то, что вхождение в файл /etc/exports некорректно.
NFS-сервис может оказаться сложным и трудным в отладке. Однако, понимание того, что именно должно быть настроено и какие имеются инструменты для диагностики проблем, безусловно, облегчит этот процесс.
Три демона должны быть запущены на сервере для того, чтобы NFS работал нормально. Это portmap, nfsd и mountd.
Сообщения следующего вида:
Looking up port of RPC 100003/2 on 192.168.0.254 portmap: server 192.168.0.254 not responding, timed out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.168.0.254 portmap: server 192.168.0.254 not responding, timed out Root-NFS: Unable to get mountd port number from server, using default mount: server 192.168.0.254 not responding, timed out Root-NFS: Server returned error -5 while mounting /opt/ltsp/i386 VFS: unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 |
обычно появляются, если демон portmap не запущен. С помощью команды ps можно проверить запущен ли portmap:
ps -e | grep portmap |
Если portmap запущен, команда должна выдать примерно следующее:
30455 ? 00:00:00 portmap |
Другим способом проверки является команда netstat. portmap использует TCP/UDP порт 111. Попробуйте следующее:
netstat -an | grep ":111 " |
Должно появиться что-то подобное:
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN udp 0 0 0.0.0.0:111 0.0.0.0:* |
Если это не так, то portmap не запущен. Запустите portmap следующим образом:
/etc/rc.d/init.d/portmap start |
Далее, необходимо убедиться в том, что настройки предполагают запуск portmap при загрузке сервера. Выполните ntsysv, чтобы убедиться, что portmap выбран для запуска.
NFS имеет 2 демона, которые должны быть запущены: nfsd и mountd. Оба демона запускаются скриптом /etc/rc.d/init.d/nfs.
Вы можете удостовериться в их работе с помощью команды ps:
ps -e | grep nfs ps -e | grep mountd |
Если один или оба демона не работают, Вам следует их запустить.
По здравому смыслу должно быть достаточно запустить скрипт с параметром restart чтобы перезапустить оба демона, но по какой-то причине скрипт /etc/rc.d/init.d/nfs не перезапускает демон nfsd: скрипт перезапускает только mountd (ошибка?). В связи с этим необходимо выполнять следующую последовательность команд:
/etc/rc.d/init.d/nfs stop /etc/rc.d/init.d/nfs start |
Команда stop может сообщать об ошибках, но это нормально. Команда start должна показывать OK в качестве статуса.
Если демоны запущены, но NFS все равно не работает, можно с помощью команды rpcinfo проверить зарегистрировали ли они себя в portmap:
rpcinfo -p localhost |
Результаты должны выглядеть примерно так:
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100011 1 udp 856 rquotad 100011 2 udp 856 rquotad 100005 1 udp 1104 mountd 100005 1 tcp 2531 mountd 100005 2 udp 1104 mountd 100005 2 tcp 2531 mountd 100003 2 udp 2049 nfs |
Это показывает, что демоны nfs (nfsd) и mountd оба запущены и зарегистрированы в portmap.
О, да! Вероятно, единственной труднейшей частью настройки рабочей станции LTSP является правильная настройка X-сервера. Если Вы используете довольно новую видеоплату, поддерживаемую XFree86, довольно новый монитор, который может работать с большим диапазоном частот и разрешений, то все проходит замечательно. Если в таких обстоятельствах графика не работает, то обычно это связано с неправильным выбором X-сервера для Вашей графической платы.
Работает ли X-сервер с Вашей графической платой или нет - обычно более чем очевидно. Либо X-сервер просто не запускается, либо отображение неправильное.
Когда процесс загрузки рабочей станции подходит к графической стадии, вызывается скрипт/tmp/start_ws, который и запускает X-сервер локальной рабочей станции с опцией -query, указывающей на сервер, на котором работает программа управления отображением, такая как XDM, GDM или KDM.
Скрипт start_ws, который вызывает X-сервер, в свою очередь, сам вызывается программой init. Если X-сервер не может запуститься, то программа init, в соответствии с ее универсальным алгоритмом, осуществит до 10 повторных запусков скрипта, после чего посчитает, что перезапуски осуществялись слишком часто, и прекратит данный процесс. При этом на экране должны остаться сообщения об ошибках от последнего запуска X-сервера.
Ждать пока X-сервер 10 раз перезапустится довольно утомительно, поэтому лучше воспользоваться способом получше: запускать рабочую станцию в runlevel 3, так чтобы X-сервер не пытался стартовать автоматически. Когда, после загрузки рабочей станции, будет выдано приглашение интерпретатора командной строки bash, стартовать X-сервер можно будет вручную:
sh /tmp/start_ws |
X-сервер попытается запуститься, а когда у него это не получится, произойдет возврат в командную строку bash, так что причину неудачного запуска можно будет увидеть на экране сразу же.
Менеджер экрана - это демон, который работает на сервере, ожидая запуска X-сервера, чтобы установить с ним соединение. Как только соединение будет установлено, менеджер экрана с помощью X-сервера отобразит на экране графическое окно входа в систему, предлагая пользователю подтвердить свои полномочия.
Наиболее известны следующие три менеджера экрана:
Как правило, все свежие дистрибутивы ОС GNU/Linux эти три менеджера уже содержат.
В этой ситуации ясно, что X-сервер работает, однако он не может установить соединение с менеджером экрана. Возможны, в частности, следующие причины:
В Redhat 7.1 менеджер экрана запускается из init. В файле /etc/inittab есть строка примерно следующего вида:
x:5:respawn:/etc/X11/prefdm -nodaemon |
Скрипт prefdm определяет тип менеджера экрана, который должен быть запущен.
Тип основного менеджера экрана зависит от того, какие пакеты установлены. Если установлен Gnome, то основным менеджером экрана будет GDM. Если же Gnome не установлен, то скрипт prefdm проверит установлен ли KDE. Если это так, то основным менеджером будет KDM. Если KDE всё-же не установлен, то основным менеджером экрана будет считаться GDM.
С помощью команды netstat можно проверить запущен ли менеджер экрана:
netstat -ap | grep xdmcp |
Полученный результат позволит определить запущен ли некий процесс, который ожидает соединений на порту xdmcp (177):
udp 0 0 *:xdmcp *:* 1493/gdm |
Такой результат однозначно указывает на то, что некий процесс gdm, имеющий PID 1493, действительно запущен, и что он ожидает соединений на порту xdmcp.
Если gdm запущен, нам необходимо убедиться в том, что рабочая станция шлёт XDMCP-запросы в правильном направлении - на правильный сервер.
В файле lts.conf может присутствовать строка, задающая IP-адрес сервера, на котором запущен менеджер экрана. Эта строка необязательная, но если она есть, должна выглядеть примерно так:
XDM_SERVER = 192.168.0.254 |
Конечно, реальный IP-адрес системы с менеджером экрана в Вашей сети может отличаться от приведённого в примере.
Если строка 'XDM_SERVER' отсутствует, будет сделана попытка задействовать строку 'SERVER'. Если же и такой строки нет, то будет IP-адрес будет задан как 192.168.0.254.
Каким бы способом ни был задан IP-адрес, необходимо лишь удостовериться в том, что он соответствует IP-адресу реального сервера с запущенным на нем менеджером экрана.
Даже если менеджер экрана запущен, он, тем не менее, может быть настроен на игнорирование XDMCP -запросов от удаленных хостов. Необходимо будет проверить конфигурационные файлы Вашего конкретного менеджера экрана для того, чтобы убедиться, что он настроен правильно.
Для дистрибутива Redhat в конфигурации по умолчанию доступ рабочих станций к XDM не разрешен. Скрипт ltsp_initialize должен позаботиться о разрешении доступа, но если что-то не сработало, придется проверить файл /etc/X11/xdm/xdm-config. Найдите нижеприведенную строку в этом файле:
DisplayManager.requestPort: 0 |
Чтобы XDM начал ожидать удаленные запросы на 177 порту, эта строка ДОЛЖНА БЫТЬ ЗАКОММЕНТИРОВАНА.
Есть ещё один конфигурационный файл XDM, необходимый для облуживания удалённых запросов на доступ. Файл называется /etc/X11/xdm/Xaccess и ДОЛЖЕН содержать строку, начинающуюся со звёздочки '*'. Обычно эта строка уже имеется в файле, но в дистрибутиве RedHat она закомментирована. Скриптltsp_initialize должен исправить ситуацию, но если XDM почему-то не работает, Вам следует ещё раз проверить этот файл. Правильная строка должна выглядеть примерно так:
* #any host can get a login window |
Новые версии KDM используют файл, называющийся kdmrc. Различные дистрибутивы Linux хранят его в различных директориях. Например, в дистрибутиве RedHat 7.2 полный путь этого файла - /etc/kde/kdm/kdmrc. В прочих дистрибутивах можно запустить команду locate для того, чтобы выяснить местонахождение этого файла.
Часть, ответственная за разрешение авторизации удалённых рабочих станций, находится в секции [Xdmcp]. Убедитесь, что опция Enable установлена в значение true.
Старые версии KDM используют конфигурационные файлы от XDM, находящиеся в директории /etc/X11/xdm.
GDM использует различные наборы конфигурационных файлов. Они находятся в директории /etc/X11/gdm.
Главный файл, в который необходимо заглянуть, - это файл gdm.conf. Найдите секцию [xdmcp]. В пределах этой секции должна быть опция 'Enable', и она должна быть установлена в '1'. Пример:
[xdmcp] Enable=true HonorIndirect=0 MaxPending=4 MaxPendingIndirect=4 MaxSessions=16 MaxWait=30 MaxWaitIndirect=30 Port=177 |
Заметили строчку 'Enable=true'? Старые версии GDM использовали '0' и '1' для определения запрета или разрешения удалённого XDMCP. Новые версии используют 'false' и 'true'.