То есть, сквошам второй стадии загрузки нельзя давать произвольное имя, о чём говорится в документации. Однако в пропагаторе произвольные имена stage2 поддерживались. Выяснилось при аналезе запроса из ALT #60692. Предлагается реализовать такую поддержку. Вопрос в том, к чему ближе произвольная стадия? К altinst, rescue или live? Мне кажется, к live, коим и rescue является. Вряд ли на одном диске будет два инсталлятора.
> Вопрос в том, к чему ближе произвольная стадия? К altinst, rescue или live? Мне кажется, к live, коим и rescue является. Да, любое имя - это именно live.
(In reply to Leonid Krivoshein from comment #0) > сквошам второй стадии загрузки нельзя давать произвольное имя В процессе разбора оказалось, что можно, но не всегда или со сторонними эффектами. > о чём говорится в документации. Там есть противоречия. С одной стороны, не поддерживается ничего, кроме altinst, rescue и live, с другой, bootchain дистронезависим. В любом случае код не соответствовал документации, плюс ещё вот это: > в пропагаторе произвольные имена stage2 поддерживались. и ряд других мелких недочётов. (In reply to Антон Мидюков from comment #1) > > Вопрос в том, к чему ближе произвольная стадия? К altinst, rescue или live? Мне кажется, к live, коим и rescue является. > Да, любое имя - это именно live. Таск #436105 мной проверен, это прототип для обсуждения изменений. Идея в том, чтобы для известных стадий altinst, rescue и live сделать использование флагов live и rescue необязательными, для остальных стадий с произвольным именем флаги rescue и live как раз будут определять, что это. Все эти флаги необязательны, а флаг live_rw теперь автоматически подразумевает live. Кроме того, показалось логичным отказаться от liverw раздела в режиме forensic. Впрочем, проверку раздела на ошибки я сделал безусловной по ряду соображений, от флага fastboot она больше не зависит.
Created attachment 22381 [details] Ошибки overlayfs после некорректного размонтирования На приведённом скриншоте видны ошибки от overlayfs, которых нет при создании R/W-раздела. Но после первой же перезагрузки они появляются в dmesg, причём время появления на скрине видно: уже после перехода в stage2, даже несмотря на успешный fsck перед монтированием. Отсюда вывод: рассинхронизация inode происходит, вероятно, из-за некорретного размонтирования раздела, это проблема где-то в stage2. Интересно, было ли такое раньше, насколько критично и можно ли это как-то вылечить?
