Created attachment 15036 [details] Скриншоты с окном и ошибкой Проблема: после выбора загрузочного носителя иногда появляется окно с выбором носителя, с которого нужно загрузиться (img1.png). Что пробовали: изменили параметры ядра на automatic=method:cdrom, timeout:20 – не принесло результата. Что выяснили (предполагаем): Данная проблема наиболее часто проявляется при использовании медленных загрузочных устройств, которые за время, установленное timout’ом, не успевают «соединиться» с машиной. При использовании устройств, обладающих большей скоростью, проблема также проявляется, но реже. 1. Метод cdrom корректно работает только с fuid; disk – с uuid; 2. При использовании cdrom и fuid требуется timeout > 20. При такой комбинации инсталлятор запускается; 3. Изменение timeout не влияет (не применяется) при использовании метода disk. При использовании такой комбинации (disk + измененный timeout) возникает ошибка (img2.png). Предлагаемые варианты исправления: 1. Вернуться к использованию cdrom и установить по-умолчанию timeout:90 (минимум) для данного метода; 2. Внести исправления в функционирование метода disk, чтобы к нему можно было применить больший timeout; 3. Внести более глобальные исправления. Создать user-friendly интерфейс: добавить возможность продления ожидания при истечении timeout; при истечении timeout выводить список текущих опций; добавить возможность ручного прерывания, при использовании продления timeout.
*** Bug 48449 has been marked as a duplicate of this bug. ***
(Ответ для alxvmr на комментарий #0) > Что пробовали: изменили параметры ядра на automatic=method:cdrom, timeout:20 И не принесёт, потому что timeout=20 по умолчанию и нужно слитно. Попробуйте: automatic=method:cdrom,timeout:90 Если поможет, можно сделать архитектурно-специфичный патчик во всех модулях, которые используют timeout. На других архитектурах с такой проблемой пока не сталкивались. Что там показывает uname -m?
(Ответ для Leonid Krivoshein на комментарий #2) > (Ответ для alxvmr на комментарий #0) > > Что пробовали: изменили параметры ядра на automatic=method:cdrom, timeout:20 > И не принесёт, потому что timeout=20 по умолчанию и нужно слитно. Попробуйте: > automatic=method:cdrom,timeout:90 > 20 секунд кажется маловато. Но и 90 секунд очень много. Возможно, можно сойтись на 30 или 45? Или на loongarch64 надо 90 секунд ждать обязательно?
(Ответ для Антон Мидюков на комментарий #3) > 20 секунд кажется маловато. В коде пропагатора где-то было жёстко забито 15, где-то 20 секунд, в зависимости от метода загрузки. Разница в altboot только в том, что для каждого метода 20 секунд -- это дефолт, который можно перебить (git grep -E '^timeout='). > Или на loongarch64 надо 90 секунд ждать обязательно? В каких-то случаях, иногда и без этого проскакивает, что указывает на особенности текущего состояния скорее ядерной части, так что я даже сомневаюсь в необходимости преодоления проблемы архитектурно-специфичным патчем, т.к. со временем эта проблема из ядра уйдёт, а этот гигантский дефолт останется.
(Ответ для alxvmr на комментарий #0) > Что выяснили (предполагаем): > 1. Метод cdrom корректно работает только с fuid; disk – с uuid; fuid был придуман sin@ для пропагаторного метода cdrom, он так и скопирован. Значение fuid и cmdline/automatic для других методов используется в altboot внутренне для чего-то другого. > 2. При использовании cdrom и fuid требуется timeout > 20. При такой > комбинации инсталлятор запускается; Успех не зависит от fuid, только от timeout. В случае метода cdrom возможно лучше использовать uuid или label с %20 вместо пробела. Изначально у fuid была странная реализация. Он используется, чтобы не загружаться с носителя, в корне диска которого нет одноимённого файла. Чтобы это проверить, носитель надо сначала примонтировать. Исходная проблема была в том, что при наличии второго недоочищенного носителя загрузка могла пойти через него и система зависала. fuid не решает эту проблему в полной мере, т.к. в случае недоочищенного носителя мы можем получить зависание на этапе монтирования или сразу после. > 3. Изменение timeout не влияет (не применяется) при использовании метода > disk. При использовании такой комбинации (disk + измененный timeout) > возникает ошибка (img2.png). Вот это я посмотрю отдельно. Как-то оно связано с обсуждаемым багом? > Предлагаемые варианты исправления: > 1. Вернуться к использованию cdrom В m-p. Согласен. Он более подходящий для гибридных ISO-образов, не переложенных на диск. Под него заточен пункт для работы RW-слоем. Не знаю, как убедить antohami@. :-) > и установить по-умолчанию timeout:90 (минимум) для данного метода; Для всех или только для loongson64? Мы ещё не сталкивались с таким, чтобы за 20 секунд локальный привод не успел обнаружиться, это даже не поднятие сети с обнаружением живого Интернет-соединения. > 2. Внести исправления в функционирование метода disk, чтобы к нему можно > было применить больший timeout; Да, это я посмотрю. > 3. Внести более глобальные исправления. Создать user-friendly интерфейс: > добавить возможность продления ожидания при истечении timeout; при истечении > timeout выводить список текущих опций; Сейчас именно так и сделано. Список опций пропагатора местами немного расширен. > добавить возможность ручного прерывания, при использовании продления timeout. С этим сложнее, но теоретически можно реализовать в рамках FR. Вопрос только зачем прерывать, что даст прерывание? Там опрос раз в секунду, так что цикл ожидания и сам прерывается раньше, когда цель достигнута.
(Ответ для Leonid Krivoshein на комментарий #5) > (Ответ для alxvmr на комментарий #0) > > Предлагаемые варианты исправления: > > 1. Вернуться к использованию cdrom > В m-p. Согласен. Он более подходящий для гибридных ISO-образов, не > переложенных на диск. Под него заточен пункт для работы RW-слоем. Не знаю, > как убедить antohami@. :-) > Не надо меня убеждать. disk для флешек предназначен, но совместим и с cdrom. Нужно исправлять его, и тогда не будет нужен отдельный метод cdrom. Никаких проблем с RW-слоем при загрузке с методом disk не выявлено.
(Ответ для Антон Мидюков на комментарий #6) > disk для флешек предназначен Совершенно точно нет. Если мы копируем ISO-образ на флешку через dd, это метод cdrom. Если мы записываем файл ISO-образа или распаковываем его на раздел отформатированной флешки или жёсткого диска, тогда это метод disk, с которым будет работать возможность overlayfs. > Нужно исправлять его, и тогда не будет нужен отдельный метод cdrom. Диалоги и логика у этих методов отличаются. Пока не вижу, что исправлять. > Никаких проблем с RW-слоем при загрузке с методом disk не выявлено. Возможно это было допилено по твоему настоянию, но изначально предлагалось отказаться от метода cdrom в пропагаторе, потому что у него в коде только на этот метод введено множество legacy-проверок, из-за которых он не находит cdrom'ы на многих современных устройствах.
Сделал патч, который увеличивает таймауты, прошу "поревьюить", применить и проверить: - https://git.altlinux.org/people/sin/packages/make-initrd-bootchain.git - https://git.altlinux.org/people/sin/packages/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=commit;h=28670b6edf31ca50b657cbce47577dbc67ddc5de
Created attachment 15062 [details] Увеличение ожидания диска с 7 до 60 секунд Непонятно, зачем делать маленький таймаут. Хотя бы минуту подождать стоит. А для method=cdrom ещё пару. При этом индикатор ожидания включается сразу. Почему он только для method=cdrom сейчас появляется?
Надо в принципе отказаться от идеи с таймаутами и ждать появления устройств.
(Ответ для Anton Farygin на комментарий #10) > Надо в принципе отказаться от идеи с таймаутами и ждать появления устройств. Вечно ожидать тоже неправильно. Причина может быть в неверно указанном uuid, или в том, что нужных модулей ядра или firmware нет в initrd. Тайм-аут можно увеличить до 60 секунд (или более) при условии, что будет возможность прервать его ожидание по ESC (сейчас этого сделать нельзя). Делать вечным нельзя, так как ESC может и не сработать в каких-то специфических условиях (serial console).
(Ответ для Антон Мидюков на комментарий #11) > Тайм-аут можно увеличить до 60 секунд (или более) при условии, что будет > возможность прервать его ожидание по ESC (сейчас этого сделать нельзя). Но тогда можно будет получить проблему из-за случайно нажатого ESC...
Вывести информационное сообщение об ожидании с возможностью отмены и таймером.
Поддерживаю rider@, мы сами к этому пришли. Но давайте последовательно. Сейчас таймауты увеличим, проблема понятна. Следующим шагом будем исправлять.
(Ответ для Evgeny Sinelnikov на комментарий #14) > Поддерживаю rider@, мы сами к этому пришли. Но давайте последовательно. > Сейчас таймауты увеличим, проблема понятна. Следующим шагом будем исправлять. Вы можете у себя в loongarch64 увеличить их ещё вчера ;)
Я полагаю, что проблема имеет более общий характер.
(Ответ для Evgeny Sinelnikov на комментарий #16) > Я полагаю, что проблема имеет более общий характер. Согласен. Только её достаточно сложно воспроизвести не на loongarch64. Поэтому можем себе позволить сделать хорошо сразу, а не частями.
(Ответ для Evgeny Sinelnikov на комментарий #9) > Увеличение ожидания диска с 7 до 60 секунд Там нет такого маленького таймаута. Везде сейчас дефолт 20 секунд. hardwait=7 внутренняя переменная совсем для других целей. > -timeout="${timeout:-20}" > +timeout="${timeout:-180}" В этом точно нет смысла, поскольку в самом make-initrd 180 секунд даётся вообще на весь процесс загрузки. > При этом индикатор ожидания включается сразу. Почему он только для method=cdrom сейчас появляется? Да, вот с этим нужно разобраться. Александр выше как-то иначе задал похожий вопрос и я как раз собираюсь посмотреть, что там не так с поведением метода disk. Однако замечу, что этот метод давно используется по дефолту в регулярках, сколько я не спорил с Антоном на эту тему. :-) (Ответ для Антон Мидюков на комментарий #17) > (Ответ для Evgeny Sinelnikov на комментарий #16) > > Я полагаю, что проблема имеет более общий характер. > Согласен. А я не согласен и написал об этом выше. > Только её достаточно сложно воспроизвести не на loongarch64. Судя по заголовку и описанию, она и на LA64 не всегда воспроизводится. Раньше в пропагаторе таймауты были меньше, их увеличивали. Последние значения для разных методов были 15-20 секунд. Именно это значение переехало в altboot оттуда, 20 секунд и начинаем бить тревогу. Для локально подключенных устройств этого должно быть достаточно. > Поэтому можем себе позволить сделать хорошо сразу, а не частями. Исправляя баг в altboot предложенным способом, мы маскируем проблему в совсем другом месте. То, что на LA64 в каких-то случаях локально подключенный диск обнаруживается аж 90 секунд, это ненормально, чинить надо именно это, если "хорошо и сразу". Увеличением таймаута для LA64 мы создаём временный костыль для этой архитектуры. Предлагаю такой вариант решения. В altboot заводим дефолтный таймаут для всех методов. Сейчас это просто константа (git grep -E '^timeout='), а можно будет конфигурировать ещё и через конфиг, для LA64 сделать это значение 90, для остальных 30 секунд. Плюс я посмотрю метод disk.
После небольшого ресёрча... (Ответ для Leonid Krivoshein на комментарий #18) > (Ответ для Evgeny Sinelnikov на комментарий #9) > > Увеличение ожидания диска с 7 до 60 секунд > Там нет такого маленького таймаута. Везде сейчас дефолт 20 секунд. > hardwait=7 внутренняя переменная совсем для других целей. В этом я оказался неправ, прошу прощения. Задумывалось иначе, а получилось как всегда. Придётся исправить. Но это говорит о том, что всё оборудование, подключенное локально, с altboot укладывалось даже в 7, а не в 20 секунд, пока не попался LA64. (Ответ для alxvmr на комментарий #0) > Метод cdrom корректно работает только с fuid По ранним тестам могу сказать, что нет -- cdrom работал с uuid. Но uuid у cdrom отличается от fuid, см. вывод blkid. Если в /proc/cmdline uuid задан верно, а на LA64 диск не обнаруживается, это может говорить о том, что там что-то не то с udev. Можно проверить так: при успешной загрузке снять sosreport и вывод blkid со вставленным загрузочным носителем. (Ответ для alxvmr на комментарий #0) > disk – с uuid В пропагаторе fuid был изобретением для метода cdrom. В altboot при пустой directory с методом disk fuid тоже используется, только файл ищется в корне смонтированного раздела. А если directory не пуста, тогда уже fuid не используется. Потому что метод disk с непустой directory предполагает, что этот параметр определяет путь к ISO-образу на подключенном разделе диска и в этом его отличие от метода cdrom, для которого тот же параметр определяет путь к сквошу второй стадии. (Ответ для alxvmr на комментарий #0) > При использовании такой комбинации (disk + измененный timeout) возникает ошибка (img2.png) Не могу до конца понять, какое влияние может оказать изменение timeout в этом случае, видимо зависит от конкретного значения, но могу утверждать, что на LA64 с методом disk видимо всегда не укладываемся в 7 секунд, тогда как с методом cdrom иногда не укладываемся в 7 секунд. Когда это происходит, с повторным сканированием проще, так как сброс параметров спецификации почти никакого влияния на метод cdrom не оказывает, в отличии от метода disk, для которого спецификация строго обязательна. Она сбрасывается через 7 секунд. Мы и с cdrom схлопочем ту же проблему, если их будет подключено два одновременно. Так как если их более одного, спецификация становится важной и для метода cdrom. (Ответ для Evgeny Sinelnikov на комментарий #9) > При этом индикатор ожидания включается сразу. Почему он только для > method=cdrom сейчас появляется? Похоже, ответ найден: потому что переключение на интерактивную консоль с диалогами при нормальной загрузке происходит по таймауту в 8 секунд. Если все шаги отработали быстрее, мы не увидим мелькание синего экрана. Но на самом деле на tty2 индикация включается сразу в main_loop(). В общем, стало понятно, что и как чинить, попробую всё исправить...
Task #334578 может исправить все проблемы, стоит проверить.
Подумалось, что если добавить plymouth в iso на loongaarch64, то он может начать успевать за 7 секунд. Ну т.е. запуск plymouth пару секунд на себя заберёт, и может хватить времени на инициализацию флешки. У меня есть медленный ноутбук, на котором такая же проблема. С недавно исправленным make-initrd и включенным plymouth за 7 секунд успевает, а если plymouth выключить, то не успевает: https://bugzilla.altlinux.org/show_bug.cgi?id=48254#c13 На этом ноутбуке таск #334578 помог. Я две секунды наблюдаю поиск при отключенном plymouth, потом загрузка идёт успешно.
(Ответ для Антон Мидюков на комментарий #21) > На этом ноутбуке таск #334578 помог. А на LA64?
Я не понимаю зачем это сделано? BC_DEBUG= BC_LOG_VT=3 +BC_DEVICE_TIMEOUT=30 +[ "$(uname -m)" != loongarch64 ] || + BC_DEVICE_TIMEOUT=90 [ ! -s /etc/sysconfig/bootchain ] || . /etc/sysconfig/bootchain Предлагаю не заниматься кроиловом и сделать всем 90 секунд. Что мы иначе выигрываем? Ответ ничего только вариативность увеличиваем. Я ещё раз хочу подчеркнуть. Проблема таймаутов не имеет архитектурной зависимости. Мы неделю подбирали "медленное" устройство, с которым эта проблема воспроизвелась.
(Ответ для Evgeny Sinelnikov на комментарий #23) > Я не понимаю зачем это сделано? > > BC_DEBUG= > BC_LOG_VT=3 > +BC_DEVICE_TIMEOUT=30 > > +[ "$(uname -m)" != loongarch64 ] || > + BC_DEVICE_TIMEOUT=90 > [ ! -s /etc/sysconfig/bootchain ] || > . /etc/sysconfig/bootchain > > Предлагаю не заниматься кроиловом и сделать всем 90 секунд. Что мы иначе > выигрываем? Ответ ничего только вариативность увеличиваем. > > Я ещё раз хочу подчеркнуть. Проблема таймаутов не имеет архитектурной > зависимости. Мы неделю подбирали "медленное" устройство, с которым эта > проблема воспроизвелась. Да, Леонид это чудо уже убрал: [#334623] TESTED make-initrd-bootchain.git=0.1.5-alt20 Будет возможность при сборке образа задать переменную с нужным тайм-аутом. Но я думаю, что вам 30 секунд хватит. Попробуйте, пожалуйста. Кнопки Cancel нет, поэтому заставлять ждать 1,5 минуты - садизм.
make-initrd-bootchain-0.1.5-alt20 -> sisyphus: Fri Nov 17 2023 Leonid Krivoshein <klark@altlinux> 0.1.5-alt20 - introduced a common default for setting timeouts - altboot: fixed localdev module (ALT #48448)
