ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Перестал отдавать адреса? | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vitaly Lipatov <lav> |
| Component: | dhcp-server | Assignee: | Mikhail Efremov <sem> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | critical | ||
| Priority: | P2 | CC: | bga, dubrsl, mike, ns, sem, solo, vvk |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Vitaly Lipatov
2005-11-14 21:11:51 MSK
У меня есть только линуксовые 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 |
