Re: [make-initrd] Wait until the resume= is processed

[Alexey Gladkov <gladkov.alexey@gmail.com>]

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