ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Странный временный нуль-маршрут ломает сетевую rootfs | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Arseny Maslennikov <arseny> | ||||||
| Component: | propagator | Assignee: | Michael Shigorin <mike> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | george, glebfm, klark.devel, klark, mav, mike, rider, sem, vseleznv | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Может, соберите уже тестовое задание? :) (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: поздравляю! :) |
Created attachment 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-сервера у меня нет.