Ещё пару месяцев назад собираемые образы установщиков обрабатывались нашим сервером сетевой установки таким образом, что в параметры загрузки ядра в PXE-меню (default) опции для локальной загрузки конвертировались во что-то вроде ... automatic=method:nfs,network:dhcp ... За это отвечает модуль alterator-netinstall. Так происходит и сейчас, и в p8, и в Sisyphus, с той лишь разницей, что пару месяцев назад этого было достаточно для сетевой загрузки, а теперь -- нет. Сейчас нужно добавлять руками на сервере в PXE-конфиг default руками ещё и server=IP,directory=/path/to/ISO-image, а если этого не сделать, propagator выводит диалог с запросом сервера и пути к ISO-файлу, и также успешно обрабатывает эти параметры. То есть, пока их не введёшь тем или иным способом, продолжение сетевой загрузки невозможно. Что-то сломалось в последние пару месяцев. Предупреждая вопрос, почему повесил не на propagator, скажу сразу: в его коде ничего подобного никогда не было, хотя это странно. Предполагаю, что раньше он мог получать эти данные по DHCP. Но поломка произошла где-то между ним и alterator-netinstall, точнее пока неизвестно. В этом году наличие проблемы подтвердили пользователи ВМК МГУ в списке рассылки sysadmins@.
Беру свои слова обратно! Описанная проблема относилась к настройке DHCP-сервера "не из коробки". К такой не совсем корректно работающей конфигурации dhcpd.conf привели сообщения о неизвестной опции "root-path" в логах. Причём вылазило неоднократно. К сожалению, после успешной настройки нескольких стендов этих сообщений воспроизвести не удалось, что это было -- не знаю. Но с alterator-netinst есть другая проблема. Создаваемый конфиг заполняется полями next-server и root-path, которые потом используются скриптами вопреки тому, как это предписано RFC. Так, для определения IP-адреса сервера NFS, используется поле next-server, для определения сетевого расположения ISO-образа используется поле root-path. См. RFC 2132 (3.19 и 9.4), https://www.ietf.org/proceedings/48/I-D/dhc-nextserver-02.txt и вот такая ещё археология: https://lkml.org/lkml/2004/1/29/3 Изначально next-server задумывался вообще для другого, но по факту давно уже можно его использовать для указания IP-адреса TFTP (но не NFS!) сервера. Чем плоха нынешняя схема, кроме нарушения стандарта: она исключает возможность масштабирования и подразумевает объединение функций DHCP, TFTP и NFS-сервера на одном хосте.
> См. RFC 2132 (3.19 и 9.4), ... Чуть не забыл самое главное: man 5 dhcp.option гласит буквально: The text data type specifies an NVT ASCII string, which must be enclosed in double quotes - for example, to specify a root-path option, the syntax would be option root-path "10.0.1.4:/var/tmp/rootfs";
(Ответ для Leonid Krivoshein на комментарий #1) > Изначально next-server задумывался вообще для другого, но по факту давно уже > можно его использовать для указания IP-адреса TFTP (но не NFS!) сервера. Чем > плоха нынешняя схема, кроме нарушения стандарта: она исключает возможность > масштабирования и подразумевает объединение функций DHCP, TFTP и NFS-сервера > на одном хосте. dhcp-сервер может и отдельный быть. Но как в случае alterator-netinst возможно разделить tftp и nfs, если манипулировать файлами мы можем только на одном сервере? Я не вижу предмета для бага тут.
(In reply to Антон Мидюков from comment #3) > Я не вижу предмета для бага тут. С закрытием бага согласен, благо и так разобрались. > dhcp-сервер может и отдельный быть. Но как в случае alterator-netinst > возможно разделить tftp и nfs, если манипулировать файлами мы можем только > на одном сервере? Переписать alterator-netinst так, чтобы иметь возможность масштабирования сетевой загрузки. См. последний абзац #34889#c1. Но это отдельная задача.
