Bug 34347 - Странный временный нуль-маршрут ломает сетевую rootfs
: Странный временный нуль-маршрут ломает сетевую rootfs
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/propagator)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2017-12-15 00:08 by
Modified: 2018-06-27 12:32 (History)


Attachments
Вариант решения, вовремя зачищающий маршрут из сабжа. (2.81 KB, patch)
2017-12-15 00:08, Arseny Maslennikov
no flags Details | Diff
later.patch (1.85 KB, patch)
2018-04-19 01:45, Leonid Krivoshein
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-12-15 00:08:04
Created an attachment (id=7317) [details]
Вариант решения, вовремя зачищающий маршрут из сабжа.

Кратко: как известно, DHCP-клиент в пропагаторе не бросается eth-фреймами в
сокет AF_PACKET, как какой-нибудь dhcpcd или ISC dhclient (и как, наверное,
следовало бы), а шлёт прямо чистый DHCP payload по UDP.
Чтобы так делать (причём через правильный интерфейс), ему нужен (временный)
IP-маршрут. Он его и создаёт с нулями вместо шлюза и маски, указывая лишь имя
настраиваемого сетевого интерфейса.
Правда, по получении DHCP ACK временный маршрут не удаляется из таблицы
маршрутизации.

Если потом его не удалять, то (уже после запуска /init) часто возникают
ситуации, когда есть помимо него маршрут с ясно указанным шлюзом, но
используется нуль-маршрут, по которому нельзя добраться, например, до сервера,
который за двумя хопами. Если там находится, на минуточку, rootfs — система
приходит в неработоспособность.

Более подробно в предисловии к прилагаемому патчу.

Мне видится два способа решения проблемы _здесь и сейчас_:
1) избавиться от необходимости в каком-то маршруте и бросаться eth-фреймами.
Соответственно, конструировать их самостоятельно.
2) (менее кардинальный) по получении DHCP ACK удалять временный маршрут и
настраивать сеть далее надлежащим образом.

Для второго варианта есть патч.
Вариант "переписать пропагатор на шелле и включить в make-initrd как фичу", как
и более мягкий вариант "вызывать внешний dhcp-клиент" — это:
во-первых, требует более крупных правок исходников;
во-вторых, не является "здесь и сейчас", а надо сейчас.

Для воспроизведения бага необходимо (не достаточно!):
1) расшарить любой дистрибутив ALT (по пути $DISTRO_ISO) по NFS,
2) загрузиться по сети с компьютера, отделённого от NFS-сервера (пусть его IP
-- $SERVER) не менее чем двумя хопами...
2.1) ..., передав ему ядро и initramfs из дистрибутива...
2.2) ..., а в Append, помимо прочего причитающегося, написав
`automatic=method:nfs,network:dhcp,server:$SERVER,directory:$DISTRO_ISO`

Не достаточно, потому что проявляется не во всяких подсетях.

Легко видеть, что для воспроизведения нужно строить либо обширный полигон
виртуалочек, либо использовать большую сеть масштаба организации (типа сети
факультета ВМК, где, собственно, симптомы и всплыли)

Предвосхищая соотв. вопрос: возможности взглянуть на конфиг DHCP-сервера у меня
нет.
------- Comment #1 From 2017-12-18 16:56:47 -------
Может, соберите уже тестовое задание? :)
------- Comment #2 From 2017-12-18 17:43:14 -------
(In reply to comment #1)
> Может, соберите уже тестовое задание? :)

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

Тестовое так тестовое. #197144
------- Comment #4 From 2017-12-20 19:14:31 -------
Коммиты глянул, локальную загрузку они (предсказуемо) не сломали;
прошу всех потенциально заинтересованных проверить сетевую загрузку
regular-rescue-20171220-x86_64.iso (454M, https://yadi.sk/d/4_qXuZ4e3Qo7nP)
и отписаться сюда в свете comment 0.
------- Comment #5 From 2018-01-17 20:37:44 -------
(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@
повесил...
------- Comment #6 From 2018-01-18 18:25:30 -------
(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

И мёртвые с косами стоят.
------- Comment #7 From 2018-02-02 21:00:16 -------
ping?
------- Comment #8 From 2018-04-10 17:17:06 -------
Дополнительная информация в списке рассылки 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 ничего подобного нет.
------- Comment #9 From 2018-04-19 01:42:13 -------
У нас тоже проблемы с сетевой загрузкой, пропагатор не может найти сетевое
устройство, потому что заглядывает в /sys/class/net слишком рано. Секунду бы -
другую подождал, и оно бы там появилось.

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

https://github.com/legionus/make-initrd (фича modules-network)
http://git.altlinux.org/people/klark/packages/deploy-project.git
------- Comment #10 From 2018-04-19 01:45:43 -------
Created an attachment (id=7502) [details]
later.patch

Кстати, раз нужно срочно, любителем "мха и палочек" я бы предложил выкинуть из
собственно пропагатора весь код, связанный с udev'ом, и сдвинуть запуск
пропагатора после udev но до loop. Это должно решить уйму проблем с
недоразвитостью пропагатора.
------- Comment #11 From 2018-04-21 11:20:46 -------
Остальные патчи к собственно пропагатору в task #205072 -- протестировал пока
только в виртуалке, только основной режим и только на p8. Попробуйте, решит ли
это ваши проблемы с загрузкой по сети.
------- Comment #12 From 2018-05-23 15:42:22 -------
(In reply to comment #11)
> Остальные патчи к собственно пропагатору в task #205072 -- протестировал пока
> только в виртуалке, только основной режим и только на p8. Попробуйте, решит ли
> это ваши проблемы с загрузкой по сети.

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

Прошу желающих/заинтересованных потестировать, а тех, кто в ACL — одобрить таск
№206842 с исправлением ошибки.
Взглянуть на образ, собранный с учётом коммитов, можно здесь:
http://mirror.cs.msu.ru/.Tld1plrHiU/regular-rescue-20180523-x86_64.iso
------- Comment #13 From 2018-05-24 03:14:39 -------
(В ответ на комментарий №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 и исхожу из
того, что вы лучше понимаете, что делаете. Георгию Курячему я уже говорил, где
у нас в сетевой загрузке совершенно точно нарушен стандарт и на что это влияет.
------- Comment #14 From 2018-06-26 20:42:18 -------
У меня в голове было отчётливое впечатление, что в changelog пакета, прошедшего
в сизиф, достаточно указать #34347, чтобы бот закрыл багрепорт — оказывается,
нет.
------- Comment #15 From 2018-06-27 12:32:36 -------
(closes: #34347) -- см.
https://www.altlinux.org/Руководство_по_написанию_changelog

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