Если указать неверный параметр init=/путь/до/init, то загрузка зацикливается на проверке sysinit: chrooted "$rootmnt" test -e "$INIT" || fatal "Unable to mount root" Это сообщение "Unable to mount root" 146 раз фигурирует в /var/log/polld.log У меня вопрос, а в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется? Такого же не может быть? А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> Если указать неверный параметр 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. Переоткрывать эту багу не надо было. Конечно же тут была совсем другая проблема, а не "то же самое".
