После обновления до dhcp-server-3.0.3-alt1.i586.rpm перестали загружаться тонкие клиенты, использующие Etherboot. Причём если загрузка через PXE, то адрес выдаётся, PXE грузится, а от etherboot запрос уже не проходит. Понять в чём причина не смог.
У меня есть только линуксовые dhcp-клиенты, больше ничего проверить не могу.
подтверждаю при получении IP обычным клиентом в логах идет Nov 17 17:33:09 gw-v22 dhcpd: DHCPDISCOVER from 00:30:18:64:86:f0 via eth1 Nov 17 17:33:09 gw-v22 dhcpd: DHCPOFFER on 192.168.7.130 to 00:30:18:64:86:f0 via eth1 Nov 17 17:33:09 gw-v22 dhcpd: DHCPREQUEST for 192.168.7.130 (192.168.7.254) from 00:30:18:64:86:f0 via eth1 Nov 17 17:33:09 gw-v22 dhcpd: DHCPACK on 192.168.7.130 to 00:30:18:64:86:f0 via eth1 при попытке получении IP после PXE Nov 17 17:34:26 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 Nov 17 17:34:26 gw-v22 dhcpd: DHCPOFFER on 192.168.7.116 to 00:03:47:22:1a:b3 via eth1 Nov 17 17:38:39 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 Nov 17 17:38:39 gw-v22 dhcpd: DHCPOFFER on 192.168.7.116 to 00:03:47:22:1a:b3 via eth1 Nov 17 17:42:53 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 Nov 17 17:42:53 gw-v22 dhcpd: DHCPOFFER on 192.168.7.116 to 00:03:47:22:1a:b3 via eth1 Nov 17 17:47:06 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 Nov 17 17:47:06 gw-v22 dhcpd: DHCPOFFER on 192.168.7.116 to 00:03:47:22:1a:b3 via eth1 Nov 17 17:51:20 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 Nov 17 17:51:20 gw-v22 dhcpd: DHCPOFFER on 192.168.7.116 to 00:03:47:22:1a:b3 via eth1 Nov 17 17:55:34 gw-v22 dhcpd: DHCPDISCOVER from 00:03:47:22:1a:b3 via eth1 ... и так в цикле похоже PXE клиент не может принять то что ему предлагают по DHCPOFFER (ругается кстати на каждый DHCPOFFER что якобы не дают ему IP) и не хочет отзываться DHCPREQUEST-ом
Ну что я могу сказать... Если вы готовы помочь с тестированием, то я могу попробовать собрать бета-версию (dhcp-3.0.4b2).
Что-то до боли знакомое.......
Опубликован релиз dhcp-3.0.4, когда соберу, можете снова проверить.
Проверьте dhcp-server-3.0.4-alt1
# rpm -q dhcp-server dhcp-server-3.0.4-alt1 То же самое. клиент не воспринимает в полученном IP-адрес и продолжает попытки
Жаль. Непонятно, чем ещё я могу вам помочь. Попадалась ли вам какая-нибудь сборка dhcp >= 3.0.4, с которой клиенты работают?
(In reply to comment #8) > Жаль. Непонятно, чем ещё я могу вам помочь. > Попадалась ли вам какая-нибудь сборка dhcp >= 3.0.4, с которой клиенты работают? Похоже http://ftp.isc.org/isc/dhcp/dhcp-3.0.5rc1.tar.gz работает.
Хорошо, соберу новый dhcpd поскорее.
Виталий, попробуйте dhcp-3.0.5-alt0.2
Всё так же: # rpm -q dhcp-server dhcp-server-3.0.5-alt0.2 Sep 14 20:41:34 server dhcpd: DHCPDISCOVER from 00:90:f5:38:8d:e0 via eth0 Sep 14 20:41:35 server dhcpd: DHCPOFFER on 192.168.0.198 to 00:90:f5:38:8d:e0 via eth0 Sep 14 20:41:36 server dhcpd: DHCPDISCOVER from 00:90:f5:38:8d:e0 via eth0 Sep 14 20:41:37 server dhcpd: DHCPOFFER on 192.168.0.197 to 00:90:f5:38:8d:e0 via eth0 Sep 14 20:41:40 server dhcpd: DHCPDISCOVER from 00:90:f5:38:8d:e0 via eth0 Sep 14 20:41:41 server dhcpd: DHCPOFFER on 192.168.0.196 to 00:90:f5:38:8d:e0 via eth0 На всякий случай в качестве клиента попробовал не только rom-o-matic, но и PXE загрузчик от nVidia в максселектовском ноуте: NVIDIA Boot Agent 216.0513 На всякий даже # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Нет, всё не так. С новым dhcp-server работает XPE-загрузчик, встроенный в BIOS'ы, и dhcp-client получает адреса. Но PXE bootstrap loader с http://rom-o-matic.net/5.4.2/ (например для via-rhine) не хочет получать адрес, выдаваемый ему dhcp-server'ом. Возможно неверные настройки сервера? Откатываюсь на 3.0.2-alt1
Всё чудесатее и чудесатее, но по прежнему вне сферы моего влияния.
Проверил загрузкой ноутбука MaxSelect A3: Feb 22 14:41:32 gate dhcpd: DHCPDISCOVER from 00:16:17:4e:04:43 via local Feb 22 14:41:33 gate dhcpd: DHCPOFFER on 192.168.1.246 to 00:16:17:4e:04:43 via local Feb 22 14:41:36 gate dhcpd: DHCPDISCOVER from 00:16:17:4e:04:43 via local Feb 22 14:41:37 gate dhcpd: DHCPOFFER on 192.168.1.245 to 00:16:17:4e:04:43 via local Feb 22 14:41:44 gate dhcpd: DHCPDISCOVER from 00:16:17:4e:04:43 via local Feb 22 14:41:45 gate dhcpd: DHCPOFFER on 192.168.1.244 to 00:16:17:4e:04:43 via local После чего пишет "не могу получить файл". Как видим, он не смог IP получить. dhcp-server-3.0.5-alt1
Это продолжалось до тех пор, пока я не добавил в /etc/dhcp/dhcpd.conf filename "/r8169.zpxe"; Оказывается, этот параметр нужен уже на этапе DHCPOFFER. Предполагаю, что и отсутствие каких-то других настроек может привести к игнорированию PXE-агентом пакетов DHCPOFFER. Проверялось на 3.0.5-alt1 в Сизифе i586 и на 3.0.2-alt1 в Мастере 2.4. Кроме того, я скачал eb-5.4.2-eepro100.zpxe для другого ноутбука (для MaxSelect такого загрузчика нет) и дошёл на нём до второй стадии: eepro100.zpxe скачивается по tftp и запускается, после чего он снова, уже сам, получает IP по DHCP и пытается скачать файл. Дальше я не настраивал, так что у меня он получал опять eepro100.zpxe, и всё по новой =). Вот мой конфиг dhcpd.conf: ddns-update-style none; subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.2; option subnet-mask 255.255.255.0; option nis-domain "domain.org"; option domain-name "domain.org"; option domain-name-servers 192.168.1.1; range dynamic-bootp 192.168.1.128 192.168.1.254; default-lease-time 21600; max-lease-time 43200; filename "/eepro100.zpxe"; next-server 192.168.1.2; } 192.168.1.2 - сервер DHCP и TFTP
Описание PXE, может, кому пригодится: http://en.wikipedia.org/wiki/Preboot_Execution_Environment
(In reply to comment #17) > Описание PXE, может, кому пригодится: Ну... вот ещё интересного из "мож пригодится" -- про загрузку из PXE не при помощи tftp/nfs, а прямиком монтируя block device поверх iSCSI или AoE (последние разработки Etherboot'чиков): http://www.linux.com/print.pl?sid=07/02/06/1856237
Во первых для PXE указание filename является обязательным. Иначе PXE-клиенту нет смысла принимать IP. Во вторых сейчас для PXE как и для Etherboot рекомендуется указать некоторые магические строчки. В понедельник я постараюсь добыть свои конфиги с прошлой работы. Если не сумею - схожу к клиенту, сниму оттуда. 2 mike: монтирование блочного девайса IMHO интересно только для blade с NAS или SAN. Но насколько я знаю лезвия обычно сами умеют грузиться с NAS или SAN.
Пытался опять. Обновил dhcp-server. История прежняя - Etherboot получает адрес, PXE - нет. Строки в конфиге такие: group { filename "/eb-5.4.2-via-rhine.zpxe"; host epia { hardware ethernet 00:40:63:C8:B7:02; fixed-address 192.168.0.3; if substring (option vendor-class-identifier, 0, 9) = "Etherboot" { filename "vmlinuz-epia"; } else { filename "/eb-5.4.2-via-rhine.zpxe"; } } }
А next-server есть?
Нет
А если указать? =) Это должен быть адрес TFTP-сервера.
Указал next-server, всё заработало. Спасибо, Григорий! Хотя так и не понял особой важности явного указания этого параметра и такого неявного его требования... # rpm -q dhcp-server dhcp-server-3.0.5-alt1
