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=gGVUGXSWz5pq95htA70j207SvlRGLdcffJI8lWkN7B8=; b=M4SlWpTTiY/Ro8mNrBBIAdQR1+QLTxkm9eT+IQmMrDp5RWgWcmZJrmGpCAONnSWCMF M038qSuBscqF2G/tLy4WdEuCLfTMlfVgq9l7u6xkqZiqlGUQd7xwaSe1Spsbpv7wcTcu j7krXpjKKz3gIh1Q2W6/YQpmfKVb6rtGcovunFjQLbHHJ0ZCs5wibY/os/J52X9QSBp4 I1Z31nal3zzbafF5Fv1UKOqAnqdbmR70SIm2zjn3htF/kuhnsa52DhPRtRWb7zYkFFQ9 xNEh+QzeJ6pc9LgokrxZwjQ+AwYb0ruq1ek0YjIXE3wfeDL5czFfGYnKn1mHBdcztu2Q WiVg== 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=gGVUGXSWz5pq95htA70j207SvlRGLdcffJI8lWkN7B8=; b=HD1BeBcNZU9+VOOGwbYhkE3VrL4CqhTzAiE64e1F59RxGWzjjYEg4rkNqvX3UOOE+s Dxt9aKnzrRGTNsgdJPO4A8Nhs8px5Fg/+Ws+ZWDVqmikhwmXEywjuNEfkdbk4TR4VTUk 043sD/t6zwLxmBZyDI5LhgJ7JjTrb9YqkypR1v2ckn4QqbAqkPYgl435BbKZWaxpMQNN sm8vwgF3nqAIhiyvv76dPXTm4jWcDnRTpXQ9pTHV3D79Dod6osB0SXZjYT2m2uU3dL2z Dvb3V6O/SvygRRk1FSENwVBRZ+tRKxdjOr0F+EftFf4W2Fx2s+20wFAdR54RGba5pGNI ImSw== X-Gm-Message-State: ACgBeo1m6OB/uGEvmEIBpd/Hw19W3BOm2Y2GSVZGVxkcuvQ/KDv700YI rnOlTyR2Gx5C7m+RIFNBvquB0t1BIPk= X-Google-Smtp-Source: AA6agR6SXmOPIWAvZCitXCiKj770mVN8Gp/zK9HSr393RjtUC0tqIS0M1aKSfKtayKj717fyb+oDxg== X-Received: by 2002:a05:6402:1388:b0:447:a3a4:6152 with SMTP id b8-20020a056402138800b00447a3a46152mr4399170edv.13.1661459046126; Thu, 25 Aug 2022 13:24:06 -0700 (PDT) Date: Thu, 25 Aug 2022 22:24:00 +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: <1aea3c9c-e713-0315-2fb5-b26b451409e7@gmail.com> 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: Thu, 25 Aug 2022 20:24:08 -0000 Archived-At: List-Archive: 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