iface = interface_select() определяет подключенный интерфейс, у которого уже есть несущая. Следующей строкой iface = get_auto_value("interface") ранее полученное значение iface игнорируется и берётся из переданного через командную строку, хотя передают его редко таким способом. Так что правильным решением это не назовёшь.

Логика последних патчей пропагатора на эту тему сводилась к тому, чтобы не было диалогов, чтобы не гадать. Но нужно оставить подключенным только один кабель и только из той посети с DHCP, откуда будет выполняться автоустановка.

 прошу реализовать правильную работу передачу названия интерфейса

или вы подтверждаете, что нельзя указывать имя сетевого интерфейса?

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

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

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

(Ответ для Alexander на комментарий #2)
> прошу реализовать правильную работу передачу названия интерфейса
https://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=blob;f=network.c#l593

Предполагаю, что правильное решение -- добавить строки:

if (choice)
    choice = strdup(choice);

перед строкой #597 или #595, поскольку free_net_devices(interfaces) освобождает память, занятую массивом (так и должно быть, вот только исходник automatic.c не был на это рассчитан). Также обратите внимание на строку #581 в network.c. Строки #635-637 -- код, который никогда не работает, следующее за ними условие:

if (sel_intf == NULL) ...

напротив, выполняется всегда. Ошибки вида SIOCSIFADDR: No such device и квадратик вместо имени интерфейса в ваших логах -- следствие потерянного имени интерфейса.

После внесения изменений пытаемся собрать новый образ boot/initrd.img
Подскажите пожалуйста при сборке образа какое должно быть содержание файла  initrd.mk ?
Какие опции необходимо использывать для команды make-initrd --kernel=uname -r ?

В данном случае я бы распаковал initrd и запаковал обратно с новым бинарём, т.к. воссоздать initrd.img иным способом сильно сложнее. Могут помочь команды из состава самого make-initrd, начиная с initrd-ls.

нет описания как сделать сильно сложнее?

Нет. Основное есть тут: https://git.altlinux.org/gears/m/mkimage.git?p=mkimage.git;a=blob;f=tools/mki-build-propagator , но это лишь маленькая часть сборки официальных образов, много чего не достаёт. Для будущих версий и тех, что уже сейчас на Сизифе, это можно будет сделать просто командой make-initrd с использованием сохранённого дистрибутивного конфига.

спасибо
Что нужно сделать, чтобы следующие версии дистрибутива ALTLinux 10 были с исправлением текущей проблемы?

(Ответ для Alexander на комментарий #10)
> Что нужно сделать, чтобы следующие версии дистрибутива ALTLinux 10 были с
> исправлением текущей проблемы?
Чтобы в них попала исправленная версия пропагатора. Но большинство дистрибутивов с нумерацией 10.2 уже вышло, ожидается ещё парочка, а будущие 11.0 теоретически могут быть выпущены уже не с пропагатором. Проблема затрагивает образы на бранчах c10x, что тоже важно.

Короче, надо жестоко пинать апстримы, чтобы они что-то делали. ))

Проверено на Alt SP Server 10 x86_64 и на KWorkstation 10.1.2 x86_64

Вариант 1
Шаги:
1) Создал VM на PVE Proxmox, добавил 2 интерфейса
2) Настроил сетевую установку
3) в параметрах ядра прописал 
automatic=method:http,interface:eth1,network:dhcp,server:192.168.1.1
Результат: Возникает ошибка при загрузке( не может определить интерфейс,см скрин)

Вариант 2:
Если не указывать в параметрах ядра интерфейс, то установка проходит успешно с первого интерфейса eth0

Вариант 3:
Если прописать в параметрах ядра
automatic=0
Выбрать HTTP > нужный интерфейс(любой) > DHCP
То установка проходит успешно с любого выбранного интерфейса

Ошибка заключается в том, что не может определить интерфейс если указывать его вручную в параметрах ядра

Created attachment 15133 [details]
screen

(Ответ для obidinog@basealt.ru на комментарий #12)
> Проверено на Alt SP Server 10 x86_64 и на KWorkstation 10.1.2 x86_64
Да, в них это исправление ещё не попало.

Имеет ли смысл держать открытыми баги на пропагатор, если он удалён из Сизифа и p11, а образов на p10 больше не ожидается? Или закрываем как WONTFIX?

(Ответ для Leonid Krivoshein на комментарий #15)
> Имеет ли смысл держать открытыми баги на пропагатор, если он удалён из
> Сизифа и p11, а образов на p10 больше не ожидается? Или закрываем как
> WONTFIX?

Имеет. Пока p10 поддерживается.

(Ответ для Антон Мидюков на комментарий #16)
> (Ответ для Leonid Krivoshein на комментарий #15)
> > Имеет ли смысл держать открытыми баги на пропагатор, если он удалён из
> > Сизифа и p11, а образов на p10 больше не ожидается? Или закрываем как
> > WONTFIX?
> 
> Имеет. Пока p10 поддерживается.

Вообще-то для загрузки по сети можно было бы собрать initrd с исправленным propagator, будь он в репозитории p10.

(In reply to Антон Мидюков from comment #17)
> Вообще-то для загрузки по сети можно было бы собрать initrd с исправленным
> propagator, будь он в репозитории p10.
https://packages.altlinux.org/ru/tasks/334829/ -- его можно собрать и после команды apt-repo test 334829, а чтобы попал в репозиторий, нужно, чтобы одобрили, висит на EPERM уже больше года. Нужно ли обновлять эту сборку?

(In reply to Антон Мидюков from comment #16)
> Имеет. Пока p10 поддерживается.
Получается, сборка конечно под p10 тогда нужна. С удалением из Сизифа никакие коммиты не потеряются?

(Ответ для Leonid Krivoshein на комментарий #19)
> (In reply to Антон Мидюков from comment #16)
> > Имеет. Пока p10 поддерживается.
> Получается, сборка конечно под p10 тогда нужна. С удалением из Сизифа
> никакие коммиты не потеряются?

Нет. Ничего не потеряется.
Собирай под p10.

(In reply to Антон Мидюков from comment #20)
> Собирай под p10.
https://packages.altlinux.org/ru/tasks/370643/ -- надо проверять. То есть, как предложил Антон выше, сборка initrd с этим пропагатором позволит решить проблему сетевой загрузки. В этом таске есть последние фиксы сборки и закрытие старых багов, которые висели в кармане с 2023 года.

Избавиться от статической линковки сходу не вышло, а хорошо бы, т.к. у нас очень давно glibc попадает в initrd.img, и ещё одна копия в ОЗУ не нужна, здесь тем более в двух экземплярах, т.к. и сам initrd в ОЗУ. При избавлении от него убираются многие страшные сообщения, но оказалось, что у нас и на p8 так было.

propagator-20250120-alt1 -> p10:

 Mon Jan 20 2025 Leonid Krivoshein <klark@altlinux> 20250120-alt1
 - improve build and spec
 Wed Nov 22 2023 Leonid Krivoshein <klark@altlinux> 20231122-alt1
 - Memory corruption fix (closes: #36751, #48516)
 Tue Nov 21 2023 Leonid Krivoshein <klark@altlinux> 20231121-alt1
 - improvements to logging during boot loading (closes #37201)