Может, соберите уже тестовое задание? :)

(In reply to comment #1)
> Может, соберите уже тестовое задание? :)

Ух ты, я думал, что раз меня в ACL пакета нет, то мне нельзя. :D
Соберу, конечно; номер задания напишу сюда.

(In reply to comment #2)
> (In reply to comment #1)
> > Может, соберите уже тестовое задание? :)
> 
> Ух ты, я думал, что раз меня в ACL пакета нет, то мне нельзя. :D
> Соберу, конечно; номер задания напишу сюда.

Тестовое так тестовое. #197144

Коммиты глянул, локальную загрузку они (предсказуемо) не сломали;
прошу всех потенциально заинтересованных проверить сетевую загрузку
regular-rescue-20171220-x86_64.iso (454M, https://yadi.sk/d/4_qXuZ4e3Qo7nP)
и отписаться сюда в свете comment 0.

(In reply to comment #4)
> Коммиты глянул, локальную загрузку они (предсказуемо) не сломали;
> прошу всех потенциально заинтересованных проверить сетевую загрузку
> regular-rescue-20171220-x86_64.iso (454M, https://yadi.sk/d/4_qXuZ4e3Qo7nP)
> и отписаться сюда в свете comment 0.

Вытащил kernel/initrd, скормил загрузчику.
Вижу newt-окошко со словами "No network device found". Shell по Alt+F2:
sh-3.2# ls /sys/class/net
lo

Аналогичное поведение на железе и в virtualbox-виртуалке.
На железе вдобавок нет реакции на клавиатуру, я пока не разбирался, почему именно.

Надо бы взглянуть в других аппаратных конфигурациях, видны ли сетевые карточки.
Руки сегодня не доходят.

> потенциально заинтересованных
А существуют ли они, кроме george@ и тех, кто участвует в переписке по этой баге? :)
Да, и на кого лучше перевесить эту багу? Я в прошлый раз нечаянно на sem@ повесил...

(In reply to comment #5)
> (In reply to comment #4)
> > Коммиты глянул, локальную загрузку они (предсказуемо) не сломали;
> > прошу всех потенциально заинтересованных проверить сетевую загрузку
> > regular-rescue-20171220-x86_64.iso (454M, https://yadi.sk/d/4_qXuZ4e3Qo7nP)
> > и отписаться сюда в свете comment 0.
> 
> Вытащил kernel/initrd, скормил загрузчику.
> Вижу newt-окошко со словами "No network device found". Shell по Alt+F2:
> sh-3.2# ls /sys/class/net
> lo
> 

sh-3.2# lsmod
Module          Size      Used by

И мёртвые с косами стоят.

ping?

Дополнительная информация в списке рассылки Sysadmins (https://lists.altlinux.org/pipermail/sysadmins/2018-April/037924.html). признаки те же - "No network Devices found". При сетевых методах установки propagator не выполняет udevadm trigger --action=add (в disk.c и cdrom.c эти вызовы были добавлены коммитом http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=ce7dbcef2b00e29fbe7c1318561d93ec07b4fe20 и переделаны коммитом http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=bc936fd7c2602099173c859cbb6e221aefc030f6
в network.c ничего подобного нет.

У нас тоже проблемы с сетевой загрузкой, пропагатор не может найти сетевое устройство, потому что заглядывает в /sys/class/net слишком рано. Секунду бы - другую подождал, и оно бы там появилось.

Заинтересованных полно. Работы по переписыванию пропагатора на шелл уже начались тихой сапой. Например:

https://github.com/legionus/make-initrd (фича modules-network)
http://git.altlinux.org/people/klark/packages/deploy-project.git

Created attachment 7502 [details]
later.patch

Кстати, раз нужно срочно, любителем "мха и палочек" я бы предложил выкинуть из собственно пропагатора весь код, связанный с udev'ом, и сдвинуть запуск пропагатора после udev но до loop. Это должно решить уйму проблем с недоразвитостью пропагатора.

Остальные патчи к собственно пропагатору в task #205072 -- протестировал пока только в виртуалке, только основной режим и только на p8. Попробуйте, решит ли это ваши проблемы с загрузкой по сети.

(In reply to comment #11)
> Остальные патчи к собственно пропагатору в task #205072 -- протестировал пока
> только в виртуалке, только основной режим и только на p8. Попробуйте, решит ли
> это ваши проблемы с загрузкой по сети.

С пропагатором 20180423-alt1 сетевые карточки действительно подхватываются (спасибо, Леонид!), но проблема из сабжа всё же ещё не решена.

Прошу желающих/заинтересованных потестировать, а тех, кто в ACL — одобрить таск №206842 с исправлением ошибки.
Взглянуть на образ, собранный с учётом коммитов, можно здесь:
http://mirror.cs.msu.ru/.Tld1plrHiU/regular-rescue-20180523-x86_64.iso

(В ответ на комментарий №12)
> С пропагатором 20180423-alt1 сетевые карточки действительно подхватываются
> (спасибо, Леонид!), но проблема из сабжа всё же ещё не решена.

Проблему с нуль-маршрутом я действительно не решал, хоть и видел ваш патч, поскольку мало что в этом понимаю. А что масштабно потестировали новую версию пропагатора -- вам отдельное спасибо!

> Прошу желающих/заинтересованных потестировать, а тех,
> кто в ACL — одобрить таск №206842 с исправлением ошибки.

Предлагаю анонсировать максимально масштабно и в devel@, и в sisyphus@ хотя бы. По предыдущему опыту желающих тестировать и ревьювить такое мало, если не сказать "нет совсем". А в данном случае тестирование ещё более сложное, поскольку нужны шлюзы. Код посмотрел и даже есть что сказать, но такие вещи обсуждать лучше в devel@. Например, вот эту цитату:

Servers that respond SHOULD only use option 43 to return the vendor-specific information to the client.

из RFC-2132 9.13 трактуют по-разному, вплоть до того, что получив от клиента опцию 60 (Vendor Class Identifier) DHCP-сервер должен ему возвращать только значение опции 43 (Vendor Specific Information), в которой закодирован и TFTP-сервер, и имя файла-образа, а опции 66 (next-server) и 67 (filename) при этом должны игнорироваться.

Но я не уверен в правильности такой трактовки RFC-2132/4361/etc и исхожу из того, что вы лучше понимаете, что делаете. Георгию Курячему я уже говорил, где у нас в сетевой загрузке совершенно точно нарушен стандарт и на что это влияет.

У меня в голове было отчётливое впечатление, что в changelog пакета, прошедшего в сизиф, достаточно указать #34347, чтобы бот закрыл багрепорт — оказывается, нет.

(closes: #34347) -- см. https://www.altlinux.org/Руководство_по_написанию_changelog

PS: поздравляю! :)