> Если указать неверный параметр init=/путь/до/init, то загрузка зацикливается на проверке sysinit

Параметры cmdline это не что-то условное, это параметры. Параметр init= указывает какую программу искать в рутовом разделе. По умолчанию ищется /sbin/init. Это основное условие для последующей загрузки - нам нужно найти программу в рутовом разделе для последующей загрузки.

> У меня вопрос, а в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется? Такого же не может быть?

Может быть так, что раздел, определённый параметром root= найден, но на нём нет указанной в init= программы. Для перехода к следующей стадии загрузки нам не только раздел, но и программа на нём, которой можно передать дальнейшее управление. Ситуация, когда рутовый раздел существует, но на нём нет /sbin/init (или того, что указано в init=) вполне возможна. Есть, например, сетевая загрузка.

> А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?

Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо действий, то в целом я согласен, но у меня сомнения про сетевые способы загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения стоит подумать о всех вариантах загрузки.

Ну и разница между монтированием root= и появлением init= может быть если реализована модная конфигурация merged-usr + split-usr, когда /sbin это симлинк на /usr/sbin и /usr на отдельном диске. Нужно смонтировать не только корень, но и раздел внутри него, чтобы условный /sbin/init стал доступен.

(Ответ для Alexey Gladkov на комментарий #1)
> > Если указать неверный параметр init=/путь/до/init, то загрузка зацикливается на проверке sysinit
> 
> Параметры cmdline это не что-то условное, это параметры. Параметр init=
> указывает какую программу искать в рутовом разделе. По умолчанию ищется
> /sbin/init. Это основное условие для последующей загрузки - нам нужно найти
> программу в рутовом разделе для последующей загрузки.
> 

Да, я это знаю.

> > У меня вопрос, а в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется? Такого же не может быть?
> 
> Может быть так, что раздел, определённый параметром root= найден, но на нём
> нет указанной в init= программы. Для перехода к следующей стадии загрузки
> нам не только раздел, но и программа на нём, которой можно передать
> дальнейшее управление. Ситуация, когда рутовый раздел существует, но на нём
> нет /sbin/init (или того, что указано в init=) вполне возможна. Есть,
> например, сетевая загрузка.
> 

Расскажите, пожалуйста, почему при сетевой загрузке на корневом разделе может не быть init? Когда и где он тогда появится?

> > А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> 
> Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет
> init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо
> действий, то в целом я согласен, но у меня сомнения про сетевые способы
> загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения
> стоит подумать о всех вариантах загрузки.

Да, я о ситуации, когда когда корневой раздел найден и смонтирован. Разве проверка sysinit работает до этого момента?

(Ответ для Alexey Gladkov на комментарий #2)
> Ну и разница между монтированием root= и появлением init= может быть если
> реализована модная конфигурация merged-usr + split-usr, когда /sbin это
> симлинк на /usr/sbin и /usr на отдельном диске. Нужно смонтировать не только
> корень, но и раздел внутри него, чтобы условный /sbin/init стал доступен.

А make-initrd уже поддерживает такую загрузку? Мне кажется, в таком случае проверка sysinit не должна включаться до монтирования /usr. И это условие должно определяться на этапе сборки initrd.

(Ответ для Антон Мидюков на комментарий #3)
> > > А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> > 
> > Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет
> > init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо
> > действий, то в целом я согласен, но у меня сомнения про сетевые способы
> > загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения
> > стоит подумать о всех вариантах загрузки.
> 
> Да, я о ситуации, когда когда корневой раздел найден и смонтирован. Разве
> проверка sysinit работает до этого момента?

Проверка работает всегда в течении rootdelay=. Мы не знаем в какой момент появятся условия для дальнейшей загрузки. Это позволяет продолжить загрузку, когда пользователь чинит что-то в rdshell и потом выходит из него.

> А make-initrd уже поддерживает такую загрузку? Мне кажется, в таком случае
> проверка sysinit не должна включаться до монтирования /usr. И это условие
> должно определяться на этапе сборки initrd.

Поддерживает. Он умеет ждать и монтировать не только / и /usr, но и другие разделы, которые укажет пользователь. В данном случае usr или не-usr роли не играет никакой. То есть в общем случае initrd ждёт не один mountpoint, а их список, наличие init= в смонтированном новом руте, и кое-каких других условий.

(Ответ для Alexey Gladkov на комментарий #4)
> (Ответ для Антон Мидюков на комментарий #3)
> > > > А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> > > 
> > > Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет
> > > init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо
> > > действий, то в целом я согласен, но у меня сомнения про сетевые способы
> > > загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения
> > > стоит подумать о всех вариантах загрузки.
> > 
> > Да, я о ситуации, когда когда корневой раздел найден и смонтирован. Разве
> > проверка sysinit работает до этого момента?
> 
> Проверка работает всегда в течении rootdelay=. Мы не знаем в какой момент
> появятся условия для дальнейшей загрузки. Это позволяет продолжить загрузку,
> когда пользователь чинит что-то в rdshell и потом выходит из него.
> 

Тогда понятно.

> > А make-initrd уже поддерживает такую загрузку? Мне кажется, в таком случае
> > проверка sysinit не должна включаться до монтирования /usr. И это условие
> > должно определяться на этапе сборки initrd.
> 
> Поддерживает. Он умеет ждать и монтировать не только / и /usr, но и другие
> разделы, которые укажет пользователь. В данном случае usr или не-usr роли не
> играет никакой. То есть в общем случае initrd ждёт не один mountpoint, а их
> список, наличие init= в смонтированном новом руте, и кое-каких других
> условий.

А что мешает в случае, когда весь список mountpoint уже смонтировался и все другие условия выполнились, но rdshell не запущен, выдать ошибку?

(Ответ для Антон Мидюков на комментарий #5)
> А что мешает в случае, когда весь список mountpoint уже смонтировался и все
> другие условия выполнились, но rdshell не запущен, выдать ошибку?

Технически ничего не мешает. Сейчас проверки никак не выделяются и выполняются как просто набор независимых скриптов. Я сходу не могу вспомнить, что может сломать такая оптимизация. Сейчас как и раньше ошибка выдаётся после истечения rootdelay=. Можно попробовать сделать оптимизацию.

В master я это поправил. Относительно скоро будет в sisyphus.

(Ответ для Alexey Gladkov на комментарий #7)
> В master я это поправил. Относительно скоро будет в sisyphus.

Проверил. Отлично!

make-initrd-2.32.0-alt1 -> sisyphus:

 Wed Oct 26 2022 Alexey Gladkov <legion@altlinux.ru> 2.32.0-alt1
 - New version (2.32.0).
 - Runtime:
   + Reduce rootdelay period if all mountpoints are done, but init program is
     missing (ALT#44111).
   + Show proper message if INIT not found.
 - Feature luks:
   + Do not overwrite LUKS_CRYPTTAB.

Created attachment 12890 [details]
Снимок экрана: не находится init там, где он есть

(Ответ для Fr. Br. George на комментарий #10)
> Создано вложение 12890 [details] [подробности]
> Снимок экрана: не находится init там, где он есть

Побверждаю эффект на regular mate 2023-03-22.
История такая же.

Время от времени загрузка по сети застревает вот в таком виде. Это сразу после синенького экрана с «ожиданием сети». Причём можно нажать Ctrl+D, и всё благополучно загружается дальше. Я думал, что это из-за медленного NFS, но нет, перенёс образ на быстрый — всё равно случается. Race какой-то? Куда смотреть хотя бы…

Месяц назад такого не было: оно долго висело в синеньком, там даже градусник доходил до 100%,  начинал идти обратно, и так иногда несколько раз — и потом стабильно грузилось.

P.S. пользователи говорят, что если *очень быстро* нажать Ctrl+D, всё виснет. Я сам не видел.

Переоткрю ошибку, явно ведь то же самое

Если можно нажать ^D и продолжить загрузку, то это похоже на рейс между монтированием NFS и проверкой mountpoint. Нужно подумать, как это лучше избежать.

(Ответ для Alexey Gladkov на комментарий #13)
> Если можно нажать ^D и продолжить загрузку, то это похоже на рейс между
> монтированием NFS и проверкой mountpoint. Нужно подумать, как это лучше
> избежать.
В самом первом сообщении сказано главное, IMHO. Вообще число 146 знаковое! :-) Убирать это проверку для bootchain нельзя, станет ещё хуже.

Научился воспроизводить на regular rescue через ventoy 1.0.88 в 100% случаев. С пропагатором проблема вообще не вылазит. При том, что схема монтирования оверлея одинаковая. Разница в ядрах -- первое на что думается. Ну и под подозрение механизм с вызовом telinit 2 на шаге root, т.е. проблеме может быть подвержен и исходный pipeline.

(Ответ для Leonid Krivoshein на комментарий #14)
> В самом первом сообщении сказано главное, IMHO. Вообще число 146 знаковое!
> :-) Убирать это проверку для bootchain нельзя, станет ещё хуже.

Насколько я понимаю по скриншоту проблема не относится к bootchain.

(Ответ для Alexey Gladkov на комментарий #15)
> (Ответ для Leonid Krivoshein на комментарий #14)
> > В самом первом сообщении сказано главное, IMHO. Вообще число 146 знаковое!
> > :-) Убирать это проверку для bootchain нельзя, станет ещё хуже.
> 
> Насколько я понимаю по скриншоту проблема не относится к bootchain.

Относится
Starting chaind service:

(Ответ для Антон Мидюков на комментарий #16)
> (Ответ для Alexey Gladkov на комментарий #15)
> > (Ответ для Leonid Krivoshein на комментарий #14)
> > > В самом первом сообщении сказано главное, IMHO. Вообще число 146 знаковое!
> > > :-) Убирать это проверку для bootchain нельзя, станет ещё хуже.
> > 
> > Насколько я понимаю по скриншоту проблема не относится к bootchain.
> 
> Относится
> Starting chaind service:

Тогда перевешиваю на него пока bootchain не исключим.

(Ответ для Alexey Gladkov на комментарий #15)
> Насколько я понимаю по скриншоту проблема не относится к bootchain.
На относится к Сизифу и новым ядрам, похоже. Новая ошибка с вываливанием в консоль в результате решения исходной проблемы происходит сразу после отработки всех шагов bootchain. То есть:

1. На самом деле проблема не решена, добавлена дополнительная проверка.
2. Причина скорее в измении поведения ядерного модуля overlayfs.

Думаю так, потому что во всех случаях мы имеем дело с монтированием корня через оверлей одинаковым набором команд, но на разных ядрах (в p10 версия меньше). У Гоши, хоть и с NFS, тоже так, т.е. оверлей строится поверх смонтированного сквоша. Доказать это будет непросто, но как я говорил, на локальной загрузке с ventoy в виртуалке воспроизводится всегда.

(Ответ для Alexey Gladkov на комментарий #17)
> Тогда перевешиваю на него пока bootchain не исключим.
На стартеркитовой rescue не воспроизводится, только на regular. Но я думаю, тут не make-initrd, не bootchain, а какая-то особенность с ядром и overlayfs. Ошибка возникает уже после того, как все файловые системы смонтированы, возможно в процессе или после вызова telinit 2. Скриншот говорит именно об этом [DONE].

Посмотрел внимательней. Раз нет сообщения о завершении, то скорее во время вызова telinit 2. Тут можно приложить журнал из /var/log/chaind.log -- для этого достаточно добавить bc_debug в параметры загрузки и он будет перенесён в stage2.

Но я уже смотрел, там нет ничего отходящего от нормы. Ситуация видимо ровно такая, как её описал Антон в первом сообщении:

У меня вопрос, а в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется? Такого же не может быть?

(Ответ для Leonid Krivoshein на комментарий #19)
> (Ответ для Alexey Gladkov на комментарий #17)
> > Тогда перевешиваю на него пока bootchain не исключим.
> На стартеркитовой rescue не воспроизводится, только на regular. Но я думаю,
> тут не make-initrd, не bootchain, а какая-то особенность с ядром и
> overlayfs. Ошибка возникает уже после того, как все файловые системы
> смонтированы, возможно в процессе или после вызова telinit 2. Скриншот
> говорит именно об этом [DONE].

Народ, откройте пожалуйста новую багу и опишите в чём именно проблема. Мне сложно ориентироваться в пределах этой переоткрытой. Здесь мы исправляли вполне конкретную ситуацию и она исправлена. Если это вызывает другую ошибку, то это новая ошибка.

(Ответ для Leonid Krivoshein на комментарий #20)
> У меня вопрос, а в каком случае может быть так, что init в смонтированном
> корне в первые секунды нет, а потом оно чудесным образом появляется? Такого
> же не может быть?

polld (который отслеживает условия) работает параллельно ueventd. Скорее всего возникает рейс между проверками и монтированием. Хотя, это мне кажется тоже очень странным. Но можно использовать flock для того чтобы избежать рейса.

(Ответ для Fr. Br. George на комментарий #12)
> Переоткрю ошибку, явно ведь то же самое
Согласен с Алексеем, что разбираться надо в другом баге, хотя они и косвенно связаны. Просто хотелось поставить Алексея в курс дела, т.к. он точно может знать об этом больше нас. Скорее всего, дело в том, как у нас стали собираться новые ядра 6.2, в частности:

https://lists.altlinux.org/pipermail/devel-kernel/2023-March/007861.html

Поэтому предлагаю попробовать на регулярке xfce с той же пакетной базой, но только с другим ядром, где этого ещё не было. Там есть выбор: 5.15 и 6.2, на 6.2 Антон на ней уже воспроизвёл. Runtime в stage1 одинаковый. Не сможешь, я попробую чуть позже.

(Ответ для Alexey Gladkov на комментарий #21)
> Народ, откройте пожалуйста новую багу и опишите в чём именно проблема. Мне
> сложно ориентироваться в пределах этой переоткрытой. Здесь мы исправляли
> вполне конкретную ситуацию и она исправлена. Если это вызывает другую
> ошибку, то это новая ошибка.
Полностью согласен.

(Ответ для Leonid Krivoshein на комментарий #23)
> Согласен с Алексеем, что разбираться надо в другом баге, хотя они и косвенно
> связаны.

Проблема была в bootchain. Исправлено в 44061. Переоткрывать эту багу не надо было. Конечно же тут была совсем другая проблема, а не "то же самое".