Привет! Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs и связанные с этим проблемы. Если всё суммировать, то проблема лишь одна: Если swap на отдельном устройстве, то оно может проинициализироваться позже чем устройство, на котором находится корень. То есть мы не знаем по какому сценарию мы движемся. К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый через параметр resume= . Поэтому если _начать_ считать, что указанное в параметре устройство обязательно должно по явиться, то неопределённости уже не будет. Проблема в том, что сейчас устройство указанное в resume= опционально т.е. параметр может указывать на что-то от предыдущий установки, например. У меня есть соблазн сделать: 1. Ждать устройство resume= и пробовать проснуться. 2. Если устройство есть и не получилось, то обрабатывать накопившиеся эвенты для обычной загрузки. 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, выдать большое предупреждение об отсутствии resume= и грузиться нормально. 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и предупреждать, что устройства нет. В этом пункте я сильно не уверен. Что вы думаете по этому поводу ? -- Rgrds, legion
On Thu, Aug 25, 2022 at 02:41:11PM +0200, Alexey Gladkov wrote: > Привет! Hi! > Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs > и связанные с этим проблемы. > > Если всё суммировать, то проблема лишь одна: > > Если swap на отдельном устройстве, то оно может проинициализироваться > позже чем устройство, на котором находится корень. То есть мы не знаем по > какому сценарию мы движемся. > > К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый > через параметр resume= . Поэтому если _начать_ считать, что указанное в > параметре устройство обязательно должно по явиться, то неопределённости > уже не будет. > > Проблема в том, что сейчас устройство указанное в resume= опционально т.е. > параметр может указывать на что-то от предыдущий установки, например. > > У меня есть соблазн сделать: > > 1. Ждать устройство resume= и пробовать проснуться. > > 2. Если устройство есть и не получилось, то обрабатывать накопившиеся > эвенты для обычной загрузки. > > 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, > выдать большое предупреждение об отсутствии resume= и грузиться нормально. > > 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и > предупреждать, что устройства нет. В этом пункте я сильно не уверен. > > Что вы думаете по этому поводу ? 1-3 выглядит осмысленным. -- WBR, Vladimir D. Seleznev
Привет! 25.08.2022 15:41, Alexey Gladkov пишет: > Привет! > > Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs > и связанные с этим проблемы. > > Если всё суммировать, то проблема лишь одна: > > Если swap на отдельном устройстве, то оно может проинициализироваться > позже чем устройство, на котором находится корень. То есть мы не знаем по > какому сценарию мы движемся. Потому что мы следуем событиям, а не движемся по сценарию. > К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый > через параметр resume= . Поэтому если _начать_ считать, что указанное в > параметре устройство обязательно должно по явиться, то неопределённости > уже не будет. > > Проблема в том, что сейчас устройство указанное в resume= опционально т.е. > параметр может указывать на что-то от предыдущий установки, например. Это ошибка конфигурирования, которая должна вылезти боком сразу же, при первом её обнаружении. Предлагаю считать отсутствие указанного SWAP фатальной ошибкой и не загружаться, пока пользователь не прочтёт и не подтвердит руками, что он накуролесил. > У меня есть соблазн сделать: > > 1. Ждать устройство resume= и пробовать проснуться. Видимо тут имелось ввиду две вещи: 1.1. Попытаться проснуться при поступлении события о нахождении устройства SWAP. 1.2. Если истёк некий тайм-аут ожидания SWAP, по крайней мере, события можно больше не ждать. Этот тайм-аут, по идее, не должен совпадать с rootdelay, так как штатная загрузка с корня -- задача, противоположная просыпанию. > 2. Если устройство есть и не получилось, то обрабатывать накопившиеся > эвенты для обычной загрузки. > > 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, > выдать большое предупреждение об отсутствии resume= и грузиться нормально. Если resume будет неотъемлемой фичей. Интересно, получится это "ужить" с общим кодом модульно. А так, да, проверку разумней делать в одном (в этом) месте. > 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и > предупреждать, что устройства нет. В этом пункте я сильно не уверен. Нет, один initramfs может быть использован для загрузки в разных условиях, с разными параметрами. > Что вы думаете по этому поводу ? > -- С уважением, Леонид Кривошеин.
On Thu, Aug 25, 2022 at 09:08:08PM +0300, Leonid Krivoshein wrote: > Привет! > > > 25.08.2022 15:41, Alexey Gladkov пишет: > > Привет! > > > > Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs > > и связанные с этим проблемы. > > > > Если всё суммировать, то проблема лишь одна: > > > > Если swap на отдельном устройстве, то оно может проинициализироваться > > позже чем устройство, на котором находится корень. То есть мы не знаем по > > какому сценарию мы движемся. > > Потому что мы следуем событиям, а не движемся по сценарию. Нет. Даже если скрипт последовательный, то в месте, где выполняется resume и устройства для этого нет, то мы всё также не знаем нужно идти дальше или ещё ждать пока появится устройство. > > К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый > > через параметр resume= . Поэтому если _начать_ считать, что указанное в > > параметре устройство обязательно должно по явиться, то неопределённости > > уже не будет. > > > > Проблема в том, что сейчас устройство указанное в resume= опционально т.е. > > параметр может указывать на что-то от предыдущий установки, например. > > Это ошибка конфигурирования, которая должна вылезти боком сразу же, при > первом её обнаружении. Предлагаю считать отсутствие указанного SWAP > фатальной ошибкой и не загружаться, пока пользователь не прочтёт и не > подтвердит руками, что он накуролесил. Я не думаю, что ломать конфигурацию, которая успешно грузилась, это выигрышная стратегия. > > У меня есть соблазн сделать: > > > > 1. Ждать устройство resume= и пробовать проснуться. > > Видимо тут имелось ввиду две вещи: > > 1.1. Попытаться проснуться при поступлении события о нахождении > устройства SWAP. > 1.2. Если истёк некий тайм-аут ожидания SWAP, по крайней мере, события > можно больше не ждать. Этот тайм-аут, по идее, не должен совпадать с > rootdelay, так как штатная загрузка с корня -- задача, противоположная > просыпанию. В случае загрузки с диска rootdelay по сути это таймаут для инициализации блочных устройств. Мне не хочется создавать отельный параметр для отката к обычной загрузке, потому что мне пока кажется, что ситуация с неправильным параметром resume= достаточно редкая. Блокировать загрузку из-за ошибки тоже неправильно. > > 2. Если устройство есть и не получилось, то обрабатывать накопившиеся > > эвенты для обычной загрузки. > > > > 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, > > выдать большое предупреждение об отсутствии resume= и грузиться нормально. > > Если resume будет неотъемлемой фичей. Интересно, получится это "ужить" с > общим кодом модульно. А так, да, проверку разумней делать в одном (в > этом) месте. Я не очень понял. Сейчас resume не находится в фиче. Так и будет дальше. > > 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и > > предупреждать, что устройства нет. В этом пункте я сильно не уверен. > > Нет, один initramfs может быть использован для загрузки в разных > условиях, с разными параметрами. -- Rgrds, legion
25.08.2022 23:24, Alexey Gladkov пишет: > On Thu, Aug 25, 2022 at 09:08:08PM +0300, Leonid Krivoshein wrote: >> Привет! >> >> >> 25.08.2022 15:41, Alexey Gladkov пишет: >>> Привет! >>> >>> Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs >>> и связанные с этим проблемы. >>> >>> Если всё суммировать, то проблема лишь одна: >>> >>> Если swap на отдельном устройстве, то оно может проинициализироваться >>> позже чем устройство, на котором находится корень. То есть мы не знаем по >>> какому сценарию мы движемся. >> Потому что мы следуем событиям, а не движемся по сценарию. > Нет. Даже если скрипт последовательный, то в месте, где выполняется resume > и устройства для этого нет, то мы всё также не знаем нужно идти дальше или > ещё ждать пока появится устройство. Представлю себе это несколько иначе. Если в /proc/cmdline есть root=... resume=..., это означает буквально следующее: "я хочу, чтобы машина проснулась из указанного свопа, если она была введена в состояния сна, а иначе ищи этот корень и грузись, как обычно". Из этого следует, что: 1) Если неверно указана спецификация resume=, это ошибка конфигурирования, которую желательно отловить как можно скорее. После такого конфигурирования пользователю уже не удастся добиться желаемого. 2) Если неверно указана спецификация root=, машина будет уметь только нормально просыпаться и это такая же ошибка конфигурирования, приводящая в rdshell или kernel panic. 3) Эти две спецификации независимы друг от друга, но есть одно условие, которое должно быть проверено первым. Поэтому события нахождения одного и второго устройства, когда указаны оба, должны быть обработаны в такой последовательности: сначала устройство свопа, затем устройство корня. >>> К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый >>> через параметр resume= . Поэтому если _начать_ считать, что указанное в >>> параметре устройство обязательно должно по явиться, то неопределённости >>> уже не будет. >>> >>> Проблема в том, что сейчас устройство указанное в resume= опционально т.е. >>> параметр может указывать на что-то от предыдущий установки, например. >> Это ошибка конфигурирования, которая должна вылезти боком сразу же, при >> первом её обнаружении. Предлагаю считать отсутствие указанного SWAP >> фатальной ошибкой и не загружаться, пока пользователь не прочтёт и не >> подтвердит руками, что он накуролесил. > Я не думаю, что ломать конфигурацию, которая успешно грузилась, это > выигрышная стратегия. Если у пользователя что-то сломалось, а в данном случае это именно так, он должен об этом узнать как можно скорее. Тут не предлагается делать kernel panic, а просто сообщить и дождаться реакции. Вот если бы resume=... означало что-то типа "я хочу, чтобы при наличии рабочего свопа с сигнатурой данных просыпания произошёл resume", тогда да, тогда это не ошибка, resume -- такая опциональная фича загрузки. Но админы тут ожидают другого. >>> У меня есть соблазн сделать: >>> >>> 1. Ждать устройство resume= и пробовать проснуться. >> Видимо тут имелось ввиду две вещи: >> >> 1.1. Попытаться проснуться при поступлении события о нахождении >> устройства SWAP. >> 1.2. Если истёк некий тайм-аут ожидания SWAP, по крайней мере, события >> можно больше не ждать. Этот тайм-аут, по идее, не должен совпадать с >> rootdelay, так как штатная загрузка с корня -- задача, противоположная >> просыпанию. > В случае загрузки с диска rootdelay по сути это таймаут для инициализации > блочных устройств. > > Мне не хочется создавать отельный параметр для отката к обычной загрузке, > потому что мне пока кажется, что ситуация с неправильным параметром > resume= достаточно редкая. Блокировать загрузку из-за ошибки тоже > неправильно. Не блокировать, а временно прерывать. Если у пользователя нет уверенности в работоспособном устройстве swap, он может просто убрать resume=... из /proc/cmline или убрать из /etc/initrd.mk FEATUERS += resume. >>> 2. Если устройство есть и не получилось, то обрабатывать накопившиеся >>> эвенты для обычной загрузки. >>> >>> 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, >>> выдать большое предупреждение об отсутствии resume= и грузиться нормально. >> Если resume будет неотъемлемой фичей. Интересно, получится это "ужить" с >> общим кодом модульно. А так, да, проверку разумней делать в одном (в >> этом) месте. > Я не очень понял. Сейчас resume не находится в фиче. Так и будет дальше. > Имел ввиду, что код, связанный с проверкой готовности root, находится в одном месте, а код проверки swap находится в фиче resume. По исходной задаче, независимо от видения реализации и понимания указанной в /proc/cmdline спецификации, нужно как-то соединить логику обработки асинхронных событий в последовательную проверку сначала наличия swap, затем готовности root. >>> 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и >>> предупреждать, что устройства нет. В этом пункте я сильно не уверен. >> Нет, один initramfs может быть использован для загрузки в разных >> условиях, с разными параметрами. -- С уважением, Леонид Кривошеин.
27.08.2022 00:48, Leonid Krivoshein пишет:
>> Сейчас resume не находится в фиче. Так и будет дальше.
>>
>
> Имел ввиду, что код, связанный с проверкой готовности root, находится
> в одном месте, а код проверки swap находится в фиче resume. По
> исходной задаче, независимо от видения реализации и понимания
> указанной в /proc/cmdline спецификации, нужно как-то соединить логику
> обработки асинхронных событий в последовательную проверку сначала
> наличия swap, затем готовности root.
И видимо я упустил, когда resume перестала быть отдельной фичей. Тогда
"ужить" будет проще.
--
С уважением,
Леонид Кривошеин.
On Sat, Aug 27, 2022 at 01:56:00AM +0300, Leonid Krivoshein wrote:
>
>
> 27.08.2022 00:48, Leonid Krivoshein пишет:
> >> Сейчас resume не находится в фиче. Так и будет дальше.
> >>
> >
> > Имел ввиду, что код, связанный с проверкой готовности root, находится
> > в одном месте, а код проверки swap находится в фиче resume. По
> > исходной задаче, независимо от видения реализации и понимания
> > указанной в /proc/cmdline спецификации, нужно как-то соединить логику
> > обработки асинхронных событий в последовательную проверку сначала
> > наличия swap, затем готовности root.
>
> И видимо я упустил, когда resume перестала быть отдельной фичей. Тогда
> "ужить" будет проще.
Ты ничего не упустил. Функционал resume никогда не был в качестве фичи.
Это базовое свойство initramfs.
--
Rgrds, legion
On Sat, Aug 27, 2022 at 12:48:08AM +0300, Leonid Krivoshein wrote: > > > 25.08.2022 23:24, Alexey Gladkov пишет: > > On Thu, Aug 25, 2022 at 09:08:08PM +0300, Leonid Krivoshein wrote: > >> Привет! > >> > >> > >> 25.08.2022 15:41, Alexey Gladkov пишет: > >>> Привет! > >>> > >>> Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs > >>> и связанные с этим проблемы. > >>> > >>> Если всё суммировать, то проблема лишь одна: > >>> > >>> Если swap на отдельном устройстве, то оно может проинициализироваться > >>> позже чем устройство, на котором находится корень. То есть мы не знаем по > >>> какому сценарию мы движемся. > >> Потому что мы следуем событиям, а не движемся по сценарию. > > Нет. Даже если скрипт последовательный, то в месте, где выполняется resume > > и устройства для этого нет, то мы всё также не знаем нужно идти дальше или > > ещё ждать пока появится устройство. > > Представлю себе это несколько иначе. Если в /proc/cmdline есть root=... > resume=..., это означает буквально следующее: "я хочу, чтобы машина > проснулась из указанного свопа, если она была введена в состояния сна, а > иначе ищи этот корень и грузись, как обычно". > > Из этого следует, что: > > 1) Если неверно указана спецификация resume=, это ошибка > конфигурирования, которую желательно отловить как можно скорее. После > такого конфигурирования пользователю уже не удастся добиться желаемого. Тут сразу я не могу согласиться. Сейчас неверное указание resume= не блокирует загрузку системы. В случае ошибки в resume= мы получим лишь невозможность просыпания, но не блокировку загрузки. Нельзя ломать конфигурацию, которая до этого грузилась, даже если ты счёл какие-то опциональные параметры не корректными. > 2) Если неверно указана спецификация root=, машина будет уметь только > нормально просыпаться и это такая же ошибка конфигурирования, приводящая > в rdshell или kernel panic. Параметры root= и resume= это не одно и тоже. Не корректное их указание приводит к разным результатам. > 3) Эти две спецификации независимы друг от друга, но есть одно условие, > которое должно быть проверено первым. Поэтому события нахождения одного > и второго устройства, когда указаны оба, должны быть обработаны в такой > последовательности: сначала устройство свопа, затем устройство корня. Как раз эту последовательность я и хочу восстановить, устранив неопределённость в состоянии загрузки (resume vs boot). В обычном случае большой разницы для пользователя не будет, но если имеет место ошибка в resume=, то загрузка станет долгой, но всё ещё возможной. > >>> К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый > >>> через параметр resume= . Поэтому если _начать_ считать, что указанное в > >>> параметре устройство обязательно должно по явиться, то неопределённости > >>> уже не будет. > >>> > >>> Проблема в том, что сейчас устройство указанное в resume= опционально т.е. > >>> параметр может указывать на что-то от предыдущий установки, например. > >> Это ошибка конфигурирования, которая должна вылезти боком сразу же, при > >> первом её обнаружении. Предлагаю считать отсутствие указанного SWAP > >> фатальной ошибкой и не загружаться, пока пользователь не прочтёт и не > >> подтвердит руками, что он накуролесил. > > Я не думаю, что ломать конфигурацию, которая успешно грузилась, это > > выигрышная стратегия. > > Если у пользователя что-то сломалось, а в данном случае это именно так, > он должен об этом узнать как можно скорее. Тут не предлагается делать > kernel panic, а просто сообщить и дождаться реакции. Вот если бы > resume=... означало что-то типа "я хочу, чтобы при наличии рабочего > свопа с сигнатурой данных просыпания произошёл resume", тогда да, тогда > это не ошибка, resume -- такая опциональная фича загрузки. Но админы тут > ожидают другого. Сейчас resume= означает ровно то, что ты указал в кавычках. > > >>> У меня есть соблазн сделать: > >>> > >>> 1. Ждать устройство resume= и пробовать проснуться. > >> Видимо тут имелось ввиду две вещи: > >> > >> 1.1. Попытаться проснуться при поступлении события о нахождении > >> устройства SWAP. > >> 1.2. Если истёк некий тайм-аут ожидания SWAP, по крайней мере, события > >> можно больше не ждать. Этот тайм-аут, по идее, не должен совпадать с > >> rootdelay, так как штатная загрузка с корня -- задача, противоположная > >> просыпанию. > > В случае загрузки с диска rootdelay по сути это таймаут для инициализации > > блочных устройств. > > > > Мне не хочется создавать отельный параметр для отката к обычной загрузке, > > потому что мне пока кажется, что ситуация с неправильным параметром > > resume= достаточно редкая. Блокировать загрузку из-за ошибки тоже > > неправильно. > > Не блокировать, а временно прерывать. Если у пользователя нет > уверенности в работоспособном устройстве swap, он может просто убрать > resume=... из /proc/cmline или убрать из /etc/initrd.mk FEATUERS += resume. > > > >>> 2. Если устройство есть и не получилось, то обрабатывать накопившиеся > >>> эвенты для обычной загрузки. > >>> > >>> 3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay, > >>> выдать большое предупреждение об отсутствии resume= и грузиться нормально. > >> Если resume будет неотъемлемой фичей. Интересно, получится это "ужить" с > >> общим кодом модульно. А так, да, проверку разумней делать в одном (в > >> этом) месте. > > Я не очень понял. Сейчас resume не находится в фиче. Так и будет дальше. > > > > Имел ввиду, что код, связанный с проверкой готовности root, находится в > одном месте, а код проверки swap находится в фиче resume. По исходной > задаче, независимо от видения реализации и понимания указанной в > /proc/cmdline спецификации, нужно как-то соединить логику обработки > асинхронных событий в последовательную проверку сначала наличия swap, > затем готовности root. > > > >>> 4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и > >>> предупреждать, что устройства нет. В этом пункте я сильно не уверен. > >> Нет, один initramfs может быть использован для загрузки в разных > >> условиях, с разными параметрами. > > > -- > С уважением, > Леонид Кривошеин. > _______________________________________________ > Make-initrd mailing list > Make-initrd@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/make-initrd -- Rgrds, legion
27.08.2022 03:02, Alexey Gladkov пишет:
> On Sat, Aug 27, 2022 at 12:48:08AM +0300, Leonid Krivoshein wrote:
>> [...]
> [...] В случае ошибки в resume= мы получим лишь
> невозможность просыпания, но не блокировку загрузки.
>
>> [...] события нахождения одного
>> и второго устройства, когда указаны оба, должны быть обработаны в такой
>> последовательности: сначала устройство свопа, затем устройство корня.
> Как раз эту последовательность я и хочу восстановить, устранив
> неопределённость в состоянии загрузки (resume vs boot). В обычном случае
> большой разницы для пользователя не будет, но если имеет место ошибка в
> resume=, то загрузка станет долгой, но всё ещё возможной.
>
>> [...] если бы
>> resume=... означало что-то типа "я хочу, чтобы при наличии рабочего
>> свопа с сигнатурой данных просыпания произошёл resume", тогда да, тогда
>> это не ошибка, resume -- такая опциональная фича загрузки. Но админы тут
>> ожидают другого.
> Сейчас resume= означает ровно то, что ты указал в кавычках.
>
>> [...]
Мне кажется, тут согласие по всем пунктам. Потому что загрузка не
блокируется, а становится дольше. Но предупреждение при ошибке
конфигурации ты же не против вывести? Понятно, что для починки даже
плохой конфигурации всё равно придётся сначала загрузиться обычным
способом. И в части того, что надо ждать не какого-то любого первого
события, а сначала дождаться свопа, если он указан.
Ещё хорошо бы это сделать независимым от того, что в root=..., чтобы и
такие фичи, как pipeline, не "гонялись" с ожиданием свопа. Грубо говоря,
если такая финальная проверка будет выполняться после telinit 2. Если
это нельзя распараллелить, ну, значит нельзя.
--
С уважением,
Леонид Кривошеин.