* [make-initrd] Wait until the resume= is processed
@ 2022-08-25 12:41 Alexey Gladkov
2022-08-25 15:50 ` Vladimir D. Seleznev
2022-08-25 18:08 ` Leonid Krivoshein
0 siblings, 2 replies; 9+ messages in thread
From: Alexey Gladkov @ 2022-08-25 12:41 UTC (permalink / raw)
To: make-initrd
Привет!
Мне нужна ваша помощь. Я раздумывал про то как устроено resume в initramfs
и связанные с этим проблемы.
Если всё суммировать, то проблема лишь одна:
Если swap на отдельном устройстве, то оно может проинициализироваться
позже чем устройство, на котором находится корень. То есть мы не знаем по
какому сценарию мы движемся.
К счастью мы ждём не какой-нибудь swap, а вполне конкретный, определённый
через параметр resume= . Поэтому если _начать_ считать, что указанное в
параметре устройство обязательно должно по явиться, то неопределённости
уже не будет.
Проблема в том, что сейчас устройство указанное в resume= опционально т.е.
параметр может указывать на что-то от предыдущий установки, например.
У меня есть соблазн сделать:
1. Ждать устройство resume= и пробовать проснуться.
2. Если устройство есть и не получилось, то обрабатывать накопившиеся
эвенты для обычной загрузки.
3. Если мы достигли rootdelay= и resume= не появился, то сбросить delay,
выдать большое предупреждение об отсутствии resume= и грузиться нормально.
4. Возможно, при создании initramfs смотреть на resume= в /proc/cmdline и
предупреждать, что устройства нет. В этом пункте я сильно не уверен.
Что вы думаете по этому поводу ?
--
Rgrds, legion
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-25 12:41 [make-initrd] Wait until the resume= is processed Alexey Gladkov
@ 2022-08-25 15:50 ` Vladimir D. Seleznev
2022-08-25 18:08 ` Leonid Krivoshein
1 sibling, 0 replies; 9+ messages in thread
From: Vladimir D. Seleznev @ 2022-08-25 15:50 UTC (permalink / raw)
To: make-initrd
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-25 12:41 [make-initrd] Wait until the resume= is processed Alexey Gladkov
2022-08-25 15:50 ` Vladimir D. Seleznev
@ 2022-08-25 18:08 ` Leonid Krivoshein
2022-08-25 20:24 ` Alexey Gladkov
1 sibling, 1 reply; 9+ messages in thread
From: Leonid Krivoshein @ 2022-08-25 18:08 UTC (permalink / raw)
To: make-initrd
Привет!
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 может быть использован для загрузки в разных
условиях, с разными параметрами.
> Что вы думаете по этому поводу ?
>
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-25 18:08 ` Leonid Krivoshein
@ 2022-08-25 20:24 ` Alexey Gladkov
2022-08-26 21:48 ` Leonid Krivoshein
0 siblings, 1 reply; 9+ messages in thread
From: Alexey Gladkov @ 2022-08-25 20:24 UTC (permalink / raw)
To: make-initrd
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-25 20:24 ` Alexey Gladkov
@ 2022-08-26 21:48 ` Leonid Krivoshein
2022-08-26 22:56 ` Leonid Krivoshein
2022-08-27 0:02 ` Alexey Gladkov
0 siblings, 2 replies; 9+ messages in thread
From: Leonid Krivoshein @ 2022-08-26 21:48 UTC (permalink / raw)
To: make-initrd
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 может быть использован для загрузки в разных
>> условиях, с разными параметрами.
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-26 21:48 ` Leonid Krivoshein
@ 2022-08-26 22:56 ` Leonid Krivoshein
2022-08-26 23:42 ` Alexey Gladkov
2022-08-27 0:02 ` Alexey Gladkov
1 sibling, 1 reply; 9+ messages in thread
From: Leonid Krivoshein @ 2022-08-26 22:56 UTC (permalink / raw)
To: make-initrd
27.08.2022 00:48, Leonid Krivoshein пишет:
>> Сейчас resume не находится в фиче. Так и будет дальше.
>>
>
> Имел ввиду, что код, связанный с проверкой готовности root, находится
> в одном месте, а код проверки swap находится в фиче resume. По
> исходной задаче, независимо от видения реализации и понимания
> указанной в /proc/cmdline спецификации, нужно как-то соединить логику
> обработки асинхронных событий в последовательную проверку сначала
> наличия swap, затем готовности root.
И видимо я упустил, когда resume перестала быть отдельной фичей. Тогда
"ужить" будет проще.
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-26 22:56 ` Leonid Krivoshein
@ 2022-08-26 23:42 ` Alexey Gladkov
0 siblings, 0 replies; 9+ messages in thread
From: Alexey Gladkov @ 2022-08-26 23:42 UTC (permalink / raw)
To: make-initrd
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-26 21:48 ` Leonid Krivoshein
2022-08-26 22:56 ` Leonid Krivoshein
@ 2022-08-27 0:02 ` Alexey Gladkov
2022-08-27 1:01 ` Leonid Krivoshein
1 sibling, 1 reply; 9+ messages in thread
From: Alexey Gladkov @ 2022-08-27 0:02 UTC (permalink / raw)
To: make-initrd
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [make-initrd] Wait until the resume= is processed
2022-08-27 0:02 ` Alexey Gladkov
@ 2022-08-27 1:01 ` Leonid Krivoshein
0 siblings, 0 replies; 9+ messages in thread
From: Leonid Krivoshein @ 2022-08-27 1:01 UTC (permalink / raw)
To: make-initrd
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. Если
это нельзя распараллелить, ну, значит нельзя.
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-08-27 1:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-25 12:41 [make-initrd] Wait until the resume= is processed Alexey Gladkov
2022-08-25 15:50 ` Vladimir D. Seleznev
2022-08-25 18:08 ` Leonid Krivoshein
2022-08-25 20:24 ` Alexey Gladkov
2022-08-26 21:48 ` Leonid Krivoshein
2022-08-26 22:56 ` Leonid Krivoshein
2022-08-26 23:42 ` Alexey Gladkov
2022-08-27 0:02 ` Alexey Gladkov
2022-08-27 1:01 ` Leonid Krivoshein
Make-initrd development discussion
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
public-inbox-index make-initrd
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.make-initrd
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git