*** 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)