Bug 44111 - Выдавать критическую ошибку при неудачной проверки sysinit
Summary: Выдавать критическую ошибку при неудачной проверки sysinit
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: make-initrd (show other bugs)
Version: unstable
Hardware: all Linux
: P5 normal
Assignee: Alexey Gladkov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 44061
  Show dependency tree
 
Reported: 2022-10-21 18:14 MSK by Антон Мидюков
Modified: 2022-10-26 23:46 MSK (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Антон Мидюков 2022-10-21 18:14:50 MSK
Если указать неверный параметр init=/путь/до/init, то загрузка зацикливается на проверке sysinit:
chrooted "$rootmnt" test -e "$INIT" ||
        fatal "Unable to mount root"

Это сообщение "Unable to mount root" 146 раз фигурирует в /var/log/polld.log

У меня вопрос, а в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется? Такого же не может быть?
А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
Comment 1 Alexey Gladkov 2022-10-22 02:26:46 MSK
> Если указать неверный параметр init=/путь/до/init, то загрузка зацикливается на проверке sysinit

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

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

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

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

Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо действий, то в целом я согласен, но у меня сомнения про сетевые способы загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения стоит подумать о всех вариантах загрузки.
Comment 2 Alexey Gladkov 2022-10-22 03:17:47 MSK
Ну и разница между монтированием root= и появлением init= может быть если реализована модная конфигурация merged-usr + split-usr, когда /sbin это симлинк на /usr/sbin и /usr на отдельном диске. Нужно смонтировать не только корень, но и раздел внутри него, чтобы условный /sbin/init стал доступен.
Comment 3 Антон Мидюков 2022-10-22 13:05:54 MSK
(Ответ для 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.
Comment 4 Alexey Gladkov 2022-10-22 13:32:12 MSK
(Ответ для Антон Мидюков на комментарий #3)
> > > А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> > 
> > Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет
> > init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо
> > действий, то в целом я согласен, но у меня сомнения про сетевые способы
> > загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения
> > стоит подумать о всех вариантах загрузки.
> 
> Да, я о ситуации, когда когда корневой раздел найден и смонтирован. Разве
> проверка sysinit работает до этого момента?

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

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

Поддерживает. Он умеет ждать и монтировать не только / и /usr, но и другие разделы, которые укажет пользователь. В данном случае usr или не-usr роли не играет никакой. То есть в общем случае initrd ждёт не один mountpoint, а их список, наличие init= в смонтированном новом руте, и кое-каких других условий.
Comment 5 Антон Мидюков 2022-10-22 13:50:35 MSK
(Ответ для Alexey Gladkov на комментарий #4)
> (Ответ для Антон Мидюков на комментарий #3)
> > > > А если так, то почему бы критическую ошибку не выдавать на экран с вопросом "выполнить перезагрузку или запустить rdshell"?
> > > 
> > > Если вы говорите о ситуации, когда корневой раздел уже найден, но на нём нет
> > > init= программы и нам нет нужды ждать rootdelay= до выполнения каких либо
> > > действий, то в целом я согласен, но у меня сомнения про сетевые способы
> > > загрузки. Возможно, этот вариант притянут за уши, но для изменения поведения
> > > стоит подумать о всех вариантах загрузки.
> > 
> > Да, я о ситуации, когда когда корневой раздел найден и смонтирован. Разве
> > проверка sysinit работает до этого момента?
> 
> Проверка работает всегда в течении rootdelay=. Мы не знаем в какой момент
> появятся условия для дальнейшей загрузки. Это позволяет продолжить загрузку,
> когда пользователь чинит что-то в rdshell и потом выходит из него.
> 

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

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

А что мешает в случае, когда весь список mountpoint уже смонтировался и все другие условия выполнились, но rdshell не запущен, выдать ошибку?
Comment 6 Alexey Gladkov 2022-10-22 14:47:29 MSK
(Ответ для Антон Мидюков на комментарий #5)
> А что мешает в случае, когда весь список mountpoint уже смонтировался и все
> другие условия выполнились, но rdshell не запущен, выдать ошибку?

Технически ничего не мешает. Сейчас проверки никак не выделяются и выполняются как просто набор независимых скриптов. Я сходу не могу вспомнить, что может сломать такая оптимизация. Сейчас как и раньше ошибка выдаётся после истечения rootdelay=. Можно попробовать сделать оптимизацию.
Comment 7 Alexey Gladkov 2022-10-24 14:26:29 MSK
В master я это поправил. Относительно скоро будет в sisyphus.
Comment 8 Антон Мидюков 2022-10-24 17:47:26 MSK
(Ответ для Alexey Gladkov на комментарий #7)
> В master я это поправил. Относительно скоро будет в sisyphus.

Проверил. Отлично!
Comment 9 Repository Robot 2022-10-26 23:46:45 MSK
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.