Make-initrd development discussion
 help / color / mirror / Atom feed
From: Leonid Krivoshein <klark.devel@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] Wait until the resume= is processed
Date: Sat, 27 Aug 2022 00:48:08 +0300
Message-ID: <eb94c8bf-e422-5503-b4ed-a5ebafa21c72@gmail.com> (raw)
In-Reply-To: <YwfaYCXnwK6zYDGS@example.org>



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 может быть использован для загрузки в разных
>> условиях, с разными параметрами.


-- 
С уважением,
Леонид Кривошеин.


  reply	other threads:[~2022-08-26 21:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 12:41 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb94c8bf-e422-5503-b4ed-a5ebafa21c72@gmail.com \
    --to=klark.devel@gmail.com \
    --cc=make-initrd@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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