* [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