Bug 41078
| Summary: | regular: загрузка по сети не работает | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Alexey Sheplyakov <asheplyakov> | ||||
| Component: | make-initrd-bootchain | Assignee: | Leonid Krivoshein <klark> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | critical | ||||||
| Priority: | P5 | CC: | antohami, iv, klark, nir, sin | ||||
| Version: | unstable | ||||||
| Hardware: | aarch64 | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
Сетевые интерфейсы есть: $ ip -o link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65535 qdisc noqueue qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000\ link/ether 00:26:58:XX:XX:XX brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisk noop qlen 1000\ link/ether 00:26:58:XX:XX:XX brd ff:ff:ff:ff:ff:ff Created attachment 9786 [details]
Полный лог загрузки
Образ без propagator. С alt-bootchain. Подписываю на багу Леонида.
>automatic=http,nrtwork:dhcp,server:10.XX.XX.XX,directory:/altlinux/regular-xfce-20211006-aarch64.iso stagename=live earlycon=uart8250,mmio32,0x20230000 audit=0 console=ttyS0,115200n8 ignore_loglevel
1. Тут опечатка 'nrtwork'.
2. Попробуйте просто выбрать метод http в специальном меню и поотвечать на вопросы. Загрузится или нет? Чтобы работала последовательная консоль в bootchain нужно дополнительно указать параметр nottys. Иначе будет на tty2, которого может и не быть физически.
3. Аргументы командной строки должны быть другие. Сейчас буду искать какие. Если Леонид меня не опередит.
Я так понимаю, надо перед automatic= вставить root=bootchain bootchain=fg,altboot и добавить nottys чтобы bootchain рисовал диалоги при необходимости на последовательную консоль. (In reply to Антон Мидюков from comment #4) > Я так понимаю, надо перед automatic= вставить > root=bootchain bootchain=fg,altboot Не помогло. Рисует диалог "Please choose the installation method" вместо того, чтобы молча загрузиться откуда указано. > и добавить nottys чтобы bootchain рисовал диалоги при необходимости на последовательную консоль. Ещё один баг (необходимость два и более раза указывать, что консоль вот там-то) > В отличие от других методов, для загрузки образа в /dev/ramN важно правильно > указать в параметре ядра ramdisk_size размер всего ISO-образа в килобайтах. Ещё один баг. А само оно посмотреть в Content-Length не может? А не вернуть ли в регулярки пропагатор, пока разработчики bootchain устраняют эти недоработки? (In reply to Alexey Sheplyakov from comment #5) > (In reply to Антон Мидюков from comment #4) > > > Я так понимаю, надо перед automatic= вставить > > root=bootchain bootchain=fg,altboot > > Не помогло. Рисует диалог "Please choose the installation method" вместо > того, чтобы молча загрузиться откуда указано. Более того, после выбора в меню "HTTP server", следует неудачная попытка поднять сеть, которая завершается сообщением "Can't bridge up network interface. Try with other network settings, wired connection and/or cable" Что за bridge, и зачем он его пытается сделать? (In reply to Alexey Sheplyakov from comment #5) > > В отличие от других методов, для загрузки образа в /dev/ramN важно правильно > > указать в параметре ядра ramdisk_size размер всего ISO-образа в килобайтах. > > Ещё один баг. А само оно посмотреть в Content-Length не может? > ramdisk_size можно вообще не указывать. Тогда в tmpfs будет грузить. >> и добавить nottys чтобы bootchain рисовал диалоги при необходимости на последовательную консоль. > >Ещё один баг (необходимость два и более раза указывать, что консоль вот там-то) Полностью согласен. Это нужно исправлять. bootchain и altboot не поднимают сеть, этим занимается make-initrd. Он это делает лучше пропагатора, так как понимает IPv4, IPv6 и дюальный стек. Поэтому в altboot пока не тащили свою поддержку сети.
Чем говорить о неготовности altboot, спросили бы, как правильно решается ваша задача. Она решается в два этапа:
1. На стенде в конфигурации iPXE используйте что-то вроде ${net0/mac}.
iPXE> show net0/mac
net0/mac:hex = 52:54:00:12:34:56
2. Используйте в параметрах загрузки ifname=... согласно README фичи network от make-initrd.
http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=make-initrd/features/network/README.md;h=98a592f34120b23c6d43908471c028c6f7bf9a63;hb=151885481085a70415062457abbac96a3f097f50
Если это объединить, загрузчик iPXE пропишет MAC-адрес выбранного интерфейса в /proc/cmdline, make-initrd создаст udev-правило 60-persistent до поднятия сети в stage1 для того интерфейса, который вам важен.
(Ответ для Антон Мидюков на комментарий #4) > Я так понимаю, надо вставить Да, надо просто добавить в script.ipxe на сервере что-то вроде: root=bootchain bootchain=fg,altboot nottys ifname=eth0:${net0/mac} ip=eth0:dhcp4 (Ответ для Alexey Sheplyakov на комментарий #5) > Ещё один баг (необходимость два и более раза указывать, что консоль вот > там-то) Нет, это тоже не баг. Он не указывает, где консоль. nottys говорит не использовать tty'и. Ядерный параметр console=... имеет очень много вариантов написания значений, далеко не ограничиваясь ttyS0. Если подскажете, как по его значениям (или иной способ) однозначно определять отсутствие tty'ов на шеле, я могу сделать такое улучшение, что nottys будет включаться ещё и внутренне. > Ещё один баг. А само оно посмотреть в Content-Length не может? Оно так всегда и делает, если не указывать imgsize, а если опустить ramdisk_size, то грузит образ не в /dev/ramN, а на tmpfs. (In reply to Leonid Krivoshein from comment #8) > Чем говорить о неготовности altboot, Критерий очень простой. Если мне что-то пришлось менять в работающей инфрастурктуре - значит, не готов. > 1. На стенде в конфигурации iPXE используйте что-то вроде ${net0/mac}. > > iPXE> show net0/mac > net0/mac:hex = 52:54:00:12:34:56 Это не работает, если интерфейсов несколько. Ничто не гарантирует, что интерфейс, с которого загрузились, называется именно net0. > 2. Используйте в параметрах загрузки ifname=... согласно README фичи network > от make-initrd. Шнурок вставлен ровно в один интерфейс. Зачем мне гадать, какой там у него mac, или как он называется в iPXE? Этот скрипт мог бы и сам пройтись по /sys/class/net, и проверить, у кого carrier=1 (In reply to Leonid Krivoshein from comment #9) > (Ответ для Alexey Sheplyakov на комментарий #5) > > Ещё один баг (необходимость два и более раза указывать, что консоль вот > > там-то) > Нет, это тоже не баг. Он не указывает, где консоль. nottys говорит не > использовать tty'и. Ядерный параметр console=... имеет очень много вариантов > написания значений, далеко не ограничиваясь ttyS0. Если подскажете, как по > его значениям (или иной способ) однозначно определять отсутствие tty'ов на > шеле, я могу сделать такое улучшение, что nottys будет включаться ещё и > внутренне. Варианты: 1. Всегда использовать для взаимодействия с пользователем устройство /dev/console 2. Если в командной строке ядра есть параметр console=..., (не важно, что именно), то автоматически включать nottys. 3. При наличии в командной строке ядра параметра console=... (не важно, что именно) запустить screen на /dev/console, и в одном экране взаимодействовать с пользователем, а в другой - показывать логи. > > Ещё один баг. А само оно посмотреть в Content-Length не может? > Оно так всегда и делает, если не указывать imgsize, а если опустить > ramdisk_size, то грузит образ не в /dev/ramN, а на tmpfs. Значит, это баг документации. (Ответ для Alexey Sheplyakov на комментарий #10) > Это не работает, если интерфейсов несколько. Ничто не гарантирует, что > интерфейс, с которого загрузились, называется именно net0. Всё работает, см. также: https://ipxe.org/cmd/iflinkwait Обычно здесь используют netX или bootif, надо читать мануал ipxe. > Шнурок вставлен ровно в один интерфейс. Зачем мне гадать, какой там у него > mac, или как он называется в iPXE? Этот скрипт мог бы и сам пройтись по > /sys/class/net, и проверить, у кого carrier=1 Не надо гадать, просто сконфигурируйте автоматику один раз. Во всех дистрибутивах это используется для автозагрузки с выбранного в iPXE интерфейса, ищите по BOOTIF=... В make-initrd за привязку переданного загрузчиком мак-адреса к конкретному имени интерфейса отвечает параметр ifname=..., это позволяет не решать второй раз задачу, которая уже была решена на этапе iPXE-загрузки. (In reply to Leonid Krivoshein from comment #8) > 1. На стенде в конфигурации iPXE используйте что-то вроде ${net0/mac}. > > iPXE> show net0/mac > net0/mac:hex = 52:54:00:12:34:56 > > 2. Используйте в параметрах загрузки ifname=... согласно README фичи network > от make-initrd. > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob; > f=make-initrd/features/network/README.md; > h=98a592f34120b23c6d43908471c028c6f7bf9a63; > hb=151885481085a70415062457abbac96a3f097f50 > > Если это объединить, загрузчик iPXE пропишет MAC-адрес выбранного интерфейса > в /proc/cmdline, make-initrd создаст udev-правило 60-persistent до поднятия > сети в stage1 для того интерфейса, который вам важен. Тупит с минуту, потом показывает диалог "Please choose installation method", несмотря на наличие в cmdline automatic=method:http,server:10.XX.XX.XX,directory:/altlinux/regular-xfce-20211006-aarch64.iso При выборе "HTTP" пытается поднять интерфейс, но не может. > Чем говорить о неготовности altboot, Я потратил полдня на его отладку, и решил, что пусть лучше этим занимается автор(ы). (Ответ для Alexey Sheplyakov на комментарий #11) > (In reply to Leonid Krivoshein from comment #9) > > Нет, это тоже не баг. Он не указывает, где консоль. nottys говорит не > > использовать tty'и. Ядерный параметр console=... имеет очень много вариантов > > написания значений, далеко не ограничиваясь ttyS0. Если подскажете, как по > > его значениям (или иной способ) однозначно определять отсутствие tty'ов на > > шеле, я могу сделать такое улучшение, что nottys будет включаться ещё и > > внутренне. > Варианты: > > 1. Всегда использовать для взаимодействия с пользователем устройство > /dev/console Не исключаю, что мы к этому вернёмся. Но есть другой баг, где именно мелькание диалогов на большинстве конфигураций просили убрать. > 2. Если в командной строке ядра есть параметр console=..., (не важно, что > именно), то автоматически включать nottys. Плохой вариант, если почитать документацию по этому параметру. Например, там может быть tty2. > 3. При наличии в командной строке ядра параметра console=... (не важно, что > именно) > запустить screen на /dev/console, и в одном экране взаимодействовать с > пользователем, а в другой - показывать логи. Это интересней и похоже на то, что есть сейчас -- там используется openvt, а другого простого способа надёжно сохранять/восстанавливать на всех типах терминалов состояние консоли я не нашёл. > > > Ещё один баг. А само оно посмотреть в Content-Length не может? > > Оно так всегда и делает, если не указывать imgsize, а если опустить > > ramdisk_size, то грузит образ не в /dev/ramN, а на tmpfs. > > Значит, это баг документации. Документация ещё не публиковалась, но да, фича появилась недавно, после написания черновика. (Ответ для Alexey Sheplyakov на комментарий #13) > > Чем говорить о неготовности altboot, > Я потратил полдня на его отладку, и решил, что пусть лучше этим занимается > автор(ы). Ещё раз: altboot не поднимает сеть, её поднимает make-initrd. Нужно просто научиться им пользоваться. Есть ещё совсем простой вариант, добавить в загрузку только ip=dhcp или ip=dhcp4, без ifname= и заморочек с iPXE, тогда фича network make-initrd сама найдёт и поднимет какой-нибудь интерфейс. altboot всё равно какой, но если make-initrd не поднимает сеть с двумя интерфейсами на Байкале, имеет смысл перевесить этот баг на него. Если мне дадут Байкал-М, я тоже могу посмотреть. (Ответ для Alexey Sheplyakov на комментарий #6) > "Can't bridge up network interface. Try with other network settings, wired > connection and/or cable" > > Что за bridge, и зачем он его пытается сделать? Там нет никакого бриджа, данное сообщение google переводит как: "Не удается подключить сетевой интерфейс. Попробуйте использовать другие параметры сети, проводное соединение и / или кабель." > Этот скрипт мог бы и сам пройтись по > /sys/class/net, и проверить, у кого carrier=1 Насколько я помню, фича network make-initrd пытается поднять только те интерфейсы, на которых есть несущая. altboot лишь смотрит, удалось ли поднять хоть какую-то сеть за 16 секунд. Если на Байкалах этого таймаута недостаточно, можно повторно пойти по тому же пути, выбрав загрузку по http и в будущем увеличить таймаут специально для Байкалов. Также ускоряет поднятие сети ip=dhcp4, т.к. дюальный стек поднимается дольше, особенно если нет IPv6. altboot сейчас работает только с IPv4, как и propagator. В логе загрузки вижу только неправильные параметры и соответствующее сообщение от make-initrd: Network up (lo): [ DONE ] Предлагаю внести изменения на стенде и приложить лог с правильными параметрами. Не исключаю, что при сборке этого образа в stage1 не попало что-то нужное. Вы пробовали с добавлением rdshell поднять сеть руками или по DHCP? (Ответ для Alexey Sheplyakov на комментарий #10) > Критерий очень простой. Если мне что-то пришлось менять в работающей > инфрастурктуре - значит, не готов. Ошибочный критерий. Если инфрастурктура не готова к изменениям в сизифе, надо её подтягивать. Она может быть более универсальной. (In reply to Leonid Krivoshein from comment #16) > Есть ещё совсем простой вариант, добавить в загрузку только ip=dhcp или > ip=dhcp4, без ifname= и заморочек с iPXE, тогда фича network make-initrd > сама найдёт и поднимет какой-нибудь интерфейс. altboot всё равно какой, но > если make-initrd не поднимает сеть с двумя интерфейсами на Байкале, имеет > смысл перевесить этот баг на него. Если мне дадут Байкал-М, я тоже могу > посмотреть. Да хоть так, хоть эдак. [ 17.691618] Micrel KSZ9031 Gigabit PHY stmmac-1:03: *-skew-ps values should be used only with phy-mode = "rgmii" [ 17.705622] baikal-dwmac 30240000.eth0 eth0: PHY [stmmac-1:03] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 17.715799] baikal-dwmac 30240000.eth0 eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 17.723342] PHY re-inited for Baikal DWMAC [ 17.727466] dwmac1000: Master AXI performs fixed burst length [ 17.733243] baikal-dwmac 30240000.eth0 eth0: No Safety Features support found [ 17.740418] baikal-dwmac 30240000.eth0 eth0: No MAC Management Counters available [ 17.744631] usb 3-4: new high-speed USB device number 3 using xhci-hcd [ 17.747922] baikal-dwmac 30240000.eth0 eth0: IEEE 1588-2008 Advanced Timestamp supported [ 17.762771] baikal-dwmac 30240000.eth0 eth0: registered PTP clock [ 17.769179] baikal-dwmac 30240000.eth0 eth0: configuring for phy/rgmii-id link mode [skipped] [ 33.944743] Network up (eth0): [ DONE ] [ 34.004595] Network up (lo): [ DONE ] [ 34.123040] Starting bootchained service: [ DONE ] [ 42.499955] fbcon: Taking over console [ 42.503987] Console: switching to colour frame buffer device 240x67 Дальше следует противно мигающий экран со странным сообщением "bridging up network", а секунд через 30 - не менее странное сообщение "can't bridge up network". (In reply to Leonid Krivoshein from comment #17) > (Ответ для Alexey Sheplyakov на комментарий #6) > > "Can't bridge up network interface. Try with other network settings, wired > > connection and/or cable" > > > > Что за bridge, и зачем он его пытается сделать? > Там нет никакого бриджа, данное сообщение google переводит как: "не смог подключить сетевой интерфейс" - это "couldn't BRING up (the) network interface". А "can't bridge up network interface" - это бессмысленный набор слов. А ещё б неплохо написать, какой интерфейс попытались поднять (MAC, имя), и что там не получилось (нет несущей, не получили адрес по DHCP). > (Ответ для Alexey Sheplyakov на комментарий #10) > > Критерий очень простой. Если мне что-то пришлось менять в работающей > > инфрастурктуре - значит, не готов. > Ошибочный критерий. Если инфрастурктура не готова к изменениям в сизифе, > надо её подтягивать. А пока я буду "подтягивать", тестированием и отладкой ядер и Xorg займётесь Вы. Верно? > Она может быть более универсальной. Может (и должна). Но для этого при разработке критических элементов системы (к которым относится early userspace) хоть немного думать об обратной совместимости. И ломать её только по какой-то веской причине, а не "мы решили не заморачиваться". (In reply to Leonid Krivoshein from comment #16) > Есть ещё совсем простой вариант, добавить в загрузку только ip=dhcp или > ip=dhcp4, без ifname= и заморочек с iPXE, тогда фича network make-initrd > сама найдёт и поднимет какой-нибудь интерфейс. altboot всё равно какой, но > если make-initrd не поднимает сеть с двумя интерфейсами на Байкале, имеет > смысл перевесить этот баг на него. Кажется, понял. bootchain-waitnet/data/lib/bootchain/waitnet 56 if [ ! -s "$NETBOOT_IFNAME" ]; then 57 IM_ponder_start "[ Bridging up interface... ]" 58 59 n=80 60 netdev= 61 ifaces=' ' 62 while [ $n -gt 0 ]; do 63 # shellcheck disable=SC2012 64 for netdev in $(ls /sys/class/net/) lo; do # [1] 65 [ "$netdev" != lo ] || 66 continue 67 [ -r "/sys/class/net/$netdev/flags" ] || 68 continue 69 if [ -n "${ifaces##* $netdev *}" ]; then # WTF? 70 echo add >"/sys/class/net/$netdev/uevent" # НО ЗАЧЕМ?! 71 ifaces="$ifaces $netdev " 72 fi 73 ip -4 addr show dev "$netdev" 2>/dev/null | 74 grep -qs ' inet ' && break 2 ||: # [2] 75 done 76 netdev= 77 sleep 0.2 78 n=$(( $n - 1 )) 79 done 0. Допустим изначально было 2 интерфейса - eth0, eth1. И так сложилось, что внутренний цикл начался с eth0. 1. В сторке 70 (отмеченной моим комментарием "НО ЗАЧЕМ?!") генерится uevent. Который затем обработает udev, и что-то запустит. Например, переименует интерфейс. Или заново запустит получение IP адреса. То есть имеем гонку между проверкой наличия на интерфейсе (IPv4) адреса и переименованием/перенастройкой интерфейса. Ну и присваевается ifaces=" eth0 " 2. Если udev успел переименовать интерфейс до проверки (отмеченной моим комментарием [2]), то внутренний цикл продолжится. И сгенерит ещё один uevent, уже для eth1. ifaces=" eth0 eth1 " 3. При следующем заходе во внутренний цикл (строка 64) может оказаться уже 3 интерфейса, например eth2, eth0, eth1 (потому что "старые" интерфейсы исчезают не сразу). И обработка начнётся с netdev=eth2. Условие [ -n "${ifaces##* $netdev *}" ] сработает, и снова запустится uevent, и снова переименование, и снова uevent, ... 4. Это безобразие закончится только по таймауту, и тут-то окажется, что IPv4 адресов на интерфейсах таки действительно нет. $ cat /etc/network/ifaces/eth0/iftab eth0 mac 00:26:58:42:93:79 $ cat /proc/cmdline vmlinuz initrd=initrd.img rdshell root=bootchain bootchain=fg,altboot ip=eth0:dhcp4 ifname=eth0:00:26:58:42:93:7a automatic=method:http,network:dhcp,server:10.42.0.111,directory:/altlinux/regular-xfce-20211006-aarch64.iso stagename=live earylcon=uart8250,mmio32,0x20230000 audit=0 console=ttyS0,115200n8 ignore_loglevel В командной строке ifname=eth0:00:26:58:42:93:7a, но кому интересны такие мелочи? (Ответ для Alexey Sheplyakov на комментарий #19) > неплохо написать, какой интерфейс попытались поднять (MAC, имя) Так я уже говорил, что bootchain/altboot не поднимают интерфейсы, он не знает, что пытался поднять make-initrd и почему ему не удалось этого сделать. > А пока я буду "подтягивать", тестированием и отладкой ядер и Xorg займётесь > Вы. Верно? Вы сообщаете о проблеме с новым компонентом в Сизифе, не предоставляя нормальной диагностики и требуя его убрать, хотя есть варианты: диагностировать проблему, привести свою инфраструктуру в соответствие новым реалиям, не использовать сизиф, а использовать p9, собирать образы с пропагатором. > Она может быть более универсальной. > Может (и должна). Но для этого при разработке критических элементов системы > (к которым относится early userspace) хоть немного думать об обратной > совместимости. Совместимость сохранена. Можете изложить по пунктам обратное? Введение новых параметров не относится к совместимости. ip, ifname -- то, что было уже пару лет в make-initrd. Да, фича network поднимает сеть иначе, нежели это делает propagator. > echo add >"/sys/class/net/$netdev/uevent" # НО ЗАЧЕМ?! Таков внутренний механизм make-initd вызова ранее установленного обработчика. Обработчик находится в коде фичи network. Он лишь пытается сконфигурировать интерфейс, согласно переданным через /proc/cmdline параметрам. > Кажется, понял Уже предлагал ранее поднять сеть руками или с помощью udhcpc, для этого не нужны bootchain, altboot, просто добавьте rdshell к параметрам загрузки. Также добавьте что-нибудь типа ip=dhcp4. Куда воткнут кабель -- неважно. Важно показать вывод ip a. waitnet смотрит именно ip a на всех интерфейсах, которые сконфигурированы в течении 16 секунд. Второе, что предлагалось, предоставить журнал загрузки с правильными параметрами загрузки, это не только dmesg, но и /var/log/bootchained.log. Вот из этого уже можно будет сделать какие-то выводы. Все ваши догадки по пунктам исходят из ошибочных предположений типа "Например, переименует интерфейс." вместо того, чтобы посмотреть код фичи, которая в данном случае дёргается. udev-правило переименования интерфейса в ней добавляется на более раннем этапе и только при наличии в /proc/cmdline параметра ifname= с конкретным именем и MAC-адресом. (Ответ для Alexey Sheplyakov на комментарий #21) > ip=eth0:dhcp4 ifname=eth0:00:26:58:42:93:7a > В командной строке ifname=eth0:00:26:58:42:93:7a, но кому интересны такие > мелочи? Да, вот это уже интересней. Могли ли на это повлиять последние изменения вокруг дотаскивания udev-правил в stage1, не знаю, но проблема тут явно с отработкой udev-правила /etc/udev/rules.d/60-persistent-net.rules. Я бы предложил для начала не использовать каноническое ethN при переименовании. Убрал из waitnet генерацию uevent, а заодно и назойливо мигающий диалог. Убрал из командной строки ifname: $ cat /proc/cmdline vmlinuz initrd=initrd.img rdshell root=bootchain bootchain=fg,altboot ip=dhcp4 automatic=method:http,network:dhcp,server:10.42.0.111,directory:/altlinux/regular-xfce-20211006-aarch64.iso stagename=live earylcon=uart8250,mmio32,0x20230000 audit=0 console=ttyS0,115200n8 ignore_loglevel Загрузилось, но так медленно! От запуска /init в initramfs до запуска systemd проходит секунд 40 (образ скачивается менее 10 секунд). (Ответ для Alexey Sheplyakov на комментарий #23) > Загрузилось, но так медленно! От запуска /init в initramfs до запуска > systemd проходит секунд 40 (образ скачивается менее 10 секунд). Вот и приложите журнал загрузки (bootchained.log). Похоже ошибка была потому, что udhcpc не успевает получить настройки за 16 секунд, это вполне может оказаться Байкал-М специфичный баг. Я знал, что загрузка работает вообще без шага waitnet, там дальше идёт аналогичные попытки получить размер образа по протоколу http. Раз выскакивала ошибка на шаге waitnet, значит здесь именно настройки получаются слишком долго. Однако сетевую загрузку на RPi4 неделю назад проверял Антон, и такой проблемы не было. (Ответ для Leonid Krivoshein на комментарий #24) > Вот и приложите журнал загрузки (bootchained.log). Забыл сказать: чтобы не мучиться, добавьте параметр bc_debug, тогда более информативный журнал загрузки окажется в /var/log/bootchained.log в stage2. > Похоже ошибка была потому, что udhcpc не успевает получить настройки за 16 > секунд, это вполне может оказаться Байкал-М специфичный баг. Ещё вчера я такое предположение сделал, сейчас уверен, что в waitnet достаточно просто в 2-3 раза увеличить таймаут. Можете попробовать и убедитесь, что рейсов и безобразия тут нет. Надо перевешивать баг на udhcpc тогда. > Я знал, что загрузка работает вообще без шага waitnet Убрать его из цепочки можно в этом месте (для протокола HTTP): в строке bootchain-altboot/data/lib/altboot/translate.d/100-download#5 нужно убрать "waitnet,". Но с ним загрузка работает чуть быстрее (проверено). Он нужен ещё и для того, чтобы дёрнуть фичу network на тот случай, если пользователь не указал ничего в /proc/cmdline для настройки сети. А в итоге я думаю, что должно работать как-то так: ifname=bootif0:<MAC> ip=bootif0:dhcp4 Возможно, пока с увеличением таймаута для Байкал-М. (In reply to Leonid Krivoshein from comment #22) > (Ответ для Alexey Sheplyakov на комментарий #19) > Совместимость сохранена. Можете изложить по пунктам обратное? Да. Раньше можно было загрузиться с authomatic=method:http,network:dhcp,server:NN.NN.NN.NN,directory:/path/to/image.iso а теперь надо указывать какие-то новые параметры, и всё равно они не срабатывают. > > echo add >"/sys/class/net/$netdev/uevent" # НО ЗАЧЕМ?! > Таков внутренний механизм make-initd вызова ранее установленного > обработчика. Обработчик находится в коде фичи network. Он лишь пытается > сконфигурировать интерфейс, согласно переданным через /proc/cmdline > параметрам. Вы запускаете перенастройку интерфейса, и тут же проверяете, есть ли на интерфейсе адрес. Это гонка. Это баг. udev для этой цели предоставляет udevadm trigger/udevadm settle. Наверное, и у make-initrd есть какие-то средства синхронизации. > Все ваши догадки по пунктам исходят из ошибочных предположений типа Наличие гонки в waitnet - это не догадка, а факт. > waitnet смотрит именно ip a на всех интерфейсах, > которые сконфигурированы в течении 16 секунд. 640 килобайт хватит всем, ой, это другое. > Вы сообщаете о проблеме с новым компонентом в Сизифе, не предоставляя > нормальной диагностики и требуя его убрать Я предлагаю вернуть пропагатор. Для этого не обязательно что-то убирать. Достаточно добавить в initrd.img /sbin/propagator, и запускать его из /init, если в командной строке не указано root=bootchain, например. > хотя есть варианты: диагностировать проблему Времени в сутках 24 часа, и разбираться во всём не выйдет. Самое главное - зачем заменять компонент, который уже работает. А если заменять - то зачем на новодел, а не dracut или casper какой-нибудь. > привести свою инфраструктуру в соответствие новым реалиям Время, время. > не использовать сизиф, А кто ж тогда будет тестировать ядро и Xorg в сизифе? > собирать образы с пропагатором. Вот я и предлагаю собирать образы с пропагатором. Если там будет ещё и bootchain, который можно легко отключить - мне он совершенно не помешает. > Уже предлагал ранее поднять сеть руками или с помощью udhcpc Поднимается. И что? Мне автоматическая загрузка нужна. А так-то руками я и SD-карту/флешку с нужным образом вставить могу. (На самом деле нет - легко запутаться). > Также добавьте что-нибудь типа ip=dhcp4. Куда воткнут кабель -- неважно. > Важно показать вывод ip a. > Второе, что предлагалось, предоставить журнал загрузки с правильными параметрами > загрузки, это не только dmesg, но и /var/log/bootchained.log. До него не дотянешься. С dmesg проще - я его из UART консоли скопировал. А как можно пропросить bootchain писать логи в /dev/ttyprintk? (In reply to Leonid Krivoshein from comment #24) > (Ответ для Alexey Sheplyakov на комментарий #23) > > Загрузилось, но так медленно! От запуска /init в initramfs до запуска > > systemd проходит секунд 40 (образ скачивается менее 10 секунд). > Вот и приложите журнал загрузки (bootchained.log). # ls -la /var/log/bootchained.log ls: cannot access '/var/log/bootchained.log': No such file or directory > Похоже ошибка была потому, что udhcpc не успевает получить настройки за 16 секунд, А что гарантирует, что dhcp *сервер* всегда ответит за 16 секунд? Что-то я в RFC2131 ничего такого не нашёл... Что гарантирует, что за эти 16 секунд загрузятся модули ядра? Конечно, нельзя ждать вечно, и какой-то таймаут надо задать. Но 16 секунд - это явно мало. А кроме того, неполхо бы этот таймаут сделать настраиваемым. > это вполне может оказаться Байкал-М специфичный баг. Факт в том, что для успешной загрузки пришлось выпилить генерацию uevent. (Ответ для Alexey Sheplyakov на комментарий #26) > > Совместимость сохранена. Можете изложить по пунктам обратное? > Да. Раньше можно было загрузиться с > authomatic=method:http,network:dhcp,server:NN.NN.NN.NN,directory:/path/to/ > image.iso Пропагатор никогда не умел загружаться с не распакованных ISO по FTP/HTTP. Эту новую "хотелку" мы реализовали почти одновременно. И о какой несовместимости тут речь? Замените altboot пропагатором и он будет работать с указанными параметрами. При сетевой загрузке параметры разово задаются на сервере, так что указание новых параметров -- не проблема, пропагатор их не смотрит. > Вы запускаете перенастройку интерфейса, и тут же проверяете, есть ли на > интерфейсе адрес. Это гонка. Это баг. Всё не так, а как -- я уже объяснил выше, далее смотрите код. > Наличие гонки в waitnet - это не догадка, а факт. Это очень легко доказать, увеличив таймаут в два-три раза. При гонке увеличение таймаута ничего не даст. Ещё вчера предлагал пройтись по тому же пути второй раз. Этот диалог и есть ручное увеличение таймаута. > Я предлагаю вернуть пропагатор. Я же не против... после закрытия всех его багов на массовых архитектурах, которые уже закрывает altboot. Сделаете? > Достаточно добавить в initrd.img /sbin/propagator, и запускать его из > /init, если в командной строке не указано root=bootchain, например. Да вы легко можете собрать образ без altboot/bootchain, откатив пару коммитов. Пропагатор вообще не смотрит на root=..., у него свой набор аргументов. Они друг другу не мешают. > Самое главное - зачем заменять компонент, который уже работает. Видимо вы не в курсе. Ещё в 2007 все разработчики пришли к тому, что это необходимо сделать. > А если заменять - то зачем на новодел, а не dracut или casper какой-нибудь. make-initrd -- наш, их ровестник, и он же в обычной rootfs, dracut уже есть в репозитории, но я взялся сделать связку между make-initrd и нашими stage2. > Вот я и предлагаю собирать образы с пропагатором. Если там будет ещё и > bootchain, который можно легко отключить - мне он совершенно не помешает. Посмотрите код фичи make-initrd-propagator. Вам придётся сделать что-то близкое для реализации своего желания. Потому что сейчас образы с пропагатором работают иначе. Если пропагатор и make-initrd-propagator попадают в образ, то ничего, кроме пропагатора там работать не будет. > > Уже предлагал ранее поднять сеть руками или с помощью udhcpc > Поднимается. И что? Мне автоматическая загрузка нужна. Без диагностики ничего не сделаем. > До него не дотянешься. С dmesg проще - я его из UART консоли скопировал. Ещё раз: добавьте параметр bc_debug и файл окажется в stage2 (при успехе загрузки). > А как можно пропросить bootchain писать логи в /dev/ttyprintk? Пока я эту возможность специально не добавлял. Но предполагаю, что образ initramfs должен быть собран с конфигом /etc/sysconfig/bootchain, в котором будет прописан BC_LOG_VT=printk. Как это делается на уровне m-p лучше Антона спросить -- он делал крючки для всех переменных bootchain. (Ответ для Alexey Sheplyakov на комментарий #27) > Конечно, нельзя ждать вечно, и какой-то таймаут надо задать. > Но 16 секунд - это явно мало. А кроме того, неполхо бы этот > таймаут сделать настраиваемым. Согласен. Можно увеличить специально для Байкал-М. А можно для всех. И можно сделать настраиваемым. Это совсем несложно, так как для других шагов timeout уже можно передавать через automatic=. Но вообще шаг waitnet "времянка" -- я хотел бы его заменить шагом конфигурирования сети с диалогами, этот же просто проверяет готовность сети к работе. > > это вполне может оказаться Байкал-М специфичный баг. > Факт в том, что для успешной загрузки пришлось выпилить генерацию uevent. Он станет таковым лишь после увеличения таймаута. Вот если за 40-60 секунд не будут получены настройки, тогда ДА. Но я в этом сомневаюсь примерно на 100%. Алексей, можете попробовать собрать образ с bootchain/altboot из задания #286717. Увеличил таймаут до 48 секунд, исправил сообщения и попытался реализовать другие пожелания, но ещё не проверял. Для использования /dev/ttyprintk спросите Антона Мидюкова, что нужно сделать в m-p, чтобы образ собрался с BC_LOG_VT=printk.
> if [ -n "${ifaces##* $netdev *}" ]; then # WTF?
Это защита от повторного запуска. Если интерфейс появился, waitnet единожды просит make-initrd его поднять. Не факт, что фича network станет его поднимать, это зависит от параметров и наличия несущей. Имя интерфейса добавляется в массив и эта конструкция как раз проверяет, что имени ещё нет в массиве.
(In reply to Leonid Krivoshein from comment #29) > > if [ -n "${ifaces##* $netdev *}" ]; then # WTF? > Это защита от повторного запуска. Это *попытка* защиты от повторного запуска. Имя интерфейса не обязано быть неизменным. Лучше использовать какой-то более стабильный идентификатор. MAC адрес, например. Имя поменяться оно может вследствие обработки uevent (который создаётся строкой ниже) udev'ом. Например, если в командной строке сказано ifname=foobar:AA:BB:CC:DD:EE:FF, то создаётся соответствующее udev правило. > Если интерфейс появился, waitnet единожды просит make-initrd его поднять. Не "если появился", а "если есть". "Если появился" таким способом не проверишь. Это нужно мониторить uevents, и из них выбирать с subsystem==net, action!=remove. А вообще весть этот цикл подозрительно похож на udevadm trigger --subsystem=net udevadm settle --timeout=16 > Не факт, что фича network станет его поднимать, это зависит от параметров и наличия несущей. Точно так же не факт, что несущая появиться к моменту генерации uevent вручную. Это надо бы проверять, а потом уж пытаться поднять интерфейс. А также может оказаться, что адрес на интерфейсе уже есть, и совершенно не нужно его перенастраивать ещё раз. > Имя интерфейса добавляется в массив и эта конструкция как раз проверяет, что имени ещё нет в массиве. Это понятно. Но "имени ещё нет в массиве" ничего не гарантирует. (Ответ для Alexey Sheplyakov на комментарий #30) > (In reply to Leonid Krivoshein from comment #29) > > > if [ -n "${ifaces##* $netdev *}" ]; then # WTF? > > Это защита от повторного запуска. > Это *попытка* защиты от повторного запуска. Имя интерфейса не обязано быть > неизменным. В типичной ситуации с udev да, но тут это работает несколько иначе. Переименования интерфейсов производятся сильно раньше, выше по коду, где в первом if дёргается фича network. > Лучше использовать какой-то более стабильный идентификатор. MAC адрес, > например. На самом деле в этом месте обнаружилась другая ошибка. Так что этот баг позволит закрыть не только вопрос с маленьким таймаутом, но и проблему повторного дёрганья фичи network, она пока на такое не рассчитана, но на Байкале вряд ли именно из-за этого возникла проблема. Поэтому я прошу проверить с заданием, собранным без исправления этой ошибки. > > Если интерфейс появился, waitnet единожды просит make-initrd его поднять. > А вообще весть этот цикл подозрительно похож на Чтобы не смущала отправка event скажу, что до этого тут стоял прямой вызов фичи network, автор make-initrd сказал, что здесь лучше вызывать через event, ему эта машинерия видней. make-initrd сначала устанавливает собственные фильтры и обработчики этих эвентов. > Точно так же не факт, что несущая появиться к моменту генерации uevent > вручную. Это не имеет значения, когда появится, тогда он её и сконфигурирует. > Это надо бы проверять, а потом уж пытаться поднять интерфейс. > А также может оказаться, что адрес на интерфейсе уже есть, и совершенно не > нужно его перенастраивать ещё раз. Суть этого кода в другом. Он просто ждёт появления адреса на интерфейсе. И он должен разово дёрнуть фичу network, если этого не было сделано ранее. Моя ошибка в том, что при некоторых условиях event может быть отправлен повторно, чего делать нежелательно, но вряд ли критично и вряд ли это влияет на вашу ситуацию, судя по описанию. В первый раз вы не добавляли нужных параметров в /proc/cmdline и waitnet дёргал фичу network ровно один раз. Также получив ошибку на шаге wiatnet, вы не шли на второй круг, так что фича network не дёргалась второй раз. Когда вы добавили ip=... в /proc/cmdline возникла ошибка, о которой я говорю -- waitnet дважды отправил event для каждого интерфейса. Вы убрали кусок его кода, названный "безобразием", и эта ошибка тоже ушла вместе с ним. С тем же успехом можно было совсем убрать шаг waitnet, т.к. далее там всё равно происходит многократное обращение к серверу за размером образа. Сейчас важно понять, является ли найденная ошибка критичной для вашей ситуации и специфичной для Байкал-М. Для этого собрано задание #286717. Потому что даже с этой ошибкой на RPi4 сетевая загрузка работала. (Ответ для Alexey Sheplyakov на комментарий #30) > (In reply to Leonid Krivoshein from comment #29) > > > if [ -n "${ifaces##* $netdev *}" ]; then # WTF? > > Это защита от повторного запуска. > Это *попытка* защиты от повторного запуска. Имя интерфейса не обязано быть > неизменным. > Лучше использовать какой-то более стабильный идентификатор. MAC адрес, > например. Кстати, может быть, надо будет потом посмотреть внимательней точку переименования интерфейса. Судя по описанию, переименование не срабатывало. Возможно по этой причине. По поводу сбора логов см #41097. (Ответ для Alexey Sheplyakov на комментарий #33) > По поводу сбора логов см #41097. На тему этого и других открытых багов после OSDay договорились с пресейлом, так как нет больше свободных Байкал-М. Пока, чтобы закрывать баги, нужна обратная связь. В комментарии 29 уже спрашивал, повторюсь: задание #286717 решает проблему сетевой загрузки? Если добавить bc_debug к параметрам загрузки после сборки с этим заданием доступен журнал в stage2? Сможете его приложить для понимания проблем с временем загрузки? Пока у меня не получается сделать рабочую сборку с исправлением большинства озвученных проблем, но я над этим работаю. (Ответ для Leonid Krivoshein на комментарий #34) > Пока у меня не получается сделать рабочую сборку с исправлением большинства > озвученных проблем, но я над этим работаю. Тестирование показало, что последняя сборка вполне рабочая. Отправил её в Сизиф. Она закроет все три бага. Если что не так, переоткроете тогда. make-initrd-bootchain-0.1.5-alt5 -> sisyphus: Fri Oct 15 2021 Leonid Krivoshein <klark@altlinux> 0.1.5-alt5 - fix netboot problem on very slow hardware (ALT #41078). - fix screen blinks in ponder widget (ALT #41096). - bootchain-core: adds support for the early console. - bootchain-waitnet: increase timeout and fix messages. - bootchain: reworked interaction with TTY's (ALT #41097). - bootchain-altboot: adds special actions to the main menu. - concatinate bootchain-loop back with the bootchained. - bootchain-core: daemon and log renamed to chaind. - bootchain-waitnet: bring up interfaces only once. |
Description
Alexey Sheplyakov 2021-10-08 17:08:42 MSK