From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date:from:to:cc; bh=qPv/bTwiHwsikoz0Ui1m8LZXupX4toKCiuqYj3iDv8U=; b=gGIhV1kc9AVzaCH0zGzZDz/f0KfRy0PkKTAtP2XEEaEAQ+eq7wRgyrlRo+n4u13V8X NOnvIcq+QaG2dtiXRKbWJXnmS66fnOcFg7A/4bOUTJX+9ctak6XYj2drFoininAJEFTJ xaGtrV4gnMqArMPolPkJ20iWCXM4hoatLMY0CaWtps9Axtus/M/LE6m74szhiuh0mWWP H38qDQwDIoH4MWtbxlmJhg9ehY8rFYFH7YkYHzdTr6KmYHcgueRkkEn97WAkFKMMeyPt p2DRvnfAIGQ+nyOfKLpZ6PIs+HletbWPy9oRub+TEEX669k76chRuAXNqh4HdMvNyli5 13EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date :x-gm-message-state:from:to:cc; bh=qPv/bTwiHwsikoz0Ui1m8LZXupX4toKCiuqYj3iDv8U=; b=C/AfPs3IG66w3TKtwmuockjlzPs/1ZVxv+MyxDLbSX3L29rLFGws4ssDUmaiJNXTKb nsyGOPh8ZeAb2toRqdPsxzFX3QHiMxozHckBWONKHLuZnbSrPYSKwYqUlvLcaJre2mQU jUnVxaNtdqiPfqwdqTqaggOH8rjrb1Pb37Hp8WpCDhB/6x9k/ECMSXI/1tmGDi9jFpEu 3f8eBGBYkNDQBgnmXzuFFb+Pd72e6EpqaFwzaFAzkNg3rJ7Jcv086nUgD6UbN4XX+G4O mZuk2XxHcXJqGl8zM1PUnB+sw7uA/TYlTc1ngiZ6Q90Uk/dMICbrPz2sD2lrcGeSkDCk EJBg== X-Gm-Message-State: ACgBeo0tkhFS//eZBVrbVqPJ3WBV7UyLLmtx/yuBk+eqdhb4nmUwkBrr CoQ99uP38EV4trv10clfyDOXex+LTfg= X-Google-Smtp-Source: AA6agR7IkgFpk5y7n5SRcMwj6eXStEXA24lE/v/pNEIIUtBhOJnSRT599oscv+8zBGO1RadKoYjCFw== X-Received: by 2002:a17:907:9628:b0:73d:9790:78b3 with SMTP id gb40-20020a170907962800b0073d979078b3mr6842829ejc.168.1661558557894; Fri, 26 Aug 2022 17:02:37 -0700 (PDT) Date: Sat, 27 Aug 2022 02:02:32 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <1aea3c9c-e713-0315-2fb5-b26b451409e7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [make-initrd] Wait until the resume= is processed X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2022 00:02:41 -0000 Archived-At: List-Archive: 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