Make-initrd development discussion
 help / color / mirror / Atom feed
* [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