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=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=h9gSrY7Agejlk3Vh6L9/PqhELUfwmUWdHso0NQuYXEw=; b=KR/E3DxKxAy95qCyci9oMgOnkrvWNszOWRwxbFlymINi90Wc3jm9trQlqxWIvFqY3q X6BhDYvnOzz7T/b/eo0eC8wT0LLpP38wl6uzOIen3jLcq+N0uP6olUwNMukZApcYXxHz W5zs/b4z3Z20Jknqbvx53Cvgb0ix0b0nsbq46pVMJXklm33wqTZieyUuGDacrB9NLwAH aAJeQdiimkuAkAudFejtaKT54gthnd3DidqR+AMmMd1FopjKd+4MKOhEwwEpAIfNJ2JC 1s1xS4VU2G/hdTYXDNE6GoBJgckTV7b1rzFXlwj8ymBpUCuRIdm6gWq/Ep2jTmIPg5jU fFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=h9gSrY7Agejlk3Vh6L9/PqhELUfwmUWdHso0NQuYXEw=; b=o5F2hROjgblbhHAwAE+JcCBHaz9/l6VSReLLJRHY7kwY2C/fzL1pmypki61lDwdrgL pXxovNPEWuOX1s6AjHxPhHvIzcwE7fj8PnInlJZQfw5WjZw6vKWrQcjQhCtso2bYObDk 6BsNfXV32VRJtVFdT6bmV6BfcFvKMEuLWsbCw494NzCRj+Ifnamai26K+7dF43TzfyRv pFz7rBMRrnTefCPiRP2nI6Uhwu2ByPd996DsZDhJOB98OwNCwr8Pg7PwzaYyUTZig77n XZ/PLolt4pm7bnDgBiF3zKw/+dFhK1C6GQkmtrE65a5q3+pF1vBNPiscxnxyi8csIHcj AosQ== X-Gm-Message-State: ACgBeo0gQGsu6aEaVO0RG6XhFOwAQEbusrU1UTmB6k/h+0v6RXSS5aMP RtjgVn51G7/X0/NSJ/6R46mtlk9vws8= X-Google-Smtp-Source: AA6agR6gi3wqjiMP00/zGD7gShmXe3amgZqHyLZOnCoIGUOl+GRIaNv3dZpE6vouEQdTZJtFkKN41w== X-Received: by 2002:a05:6512:10d2:b0:492:ddd1:6271 with SMTP id k18-20020a05651210d200b00492ddd16271mr2897239lfg.171.1661550490858; Fri, 26 Aug 2022 14:48:10 -0700 (PDT) Message-ID: Date: Sat, 27 Aug 2022 00:48:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.10.0 Content-Language: ru To: make-initrd@lists.altlinux.org References: <1aea3c9c-e713-0315-2fb5-b26b451409e7@gmail.com> From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 26 Aug 2022 21:48:14 -0000 Archived-At: List-Archive: 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 может быть использован для загрузки в разных >> условиях, с разными параметрами. -- С уважением, Леонид Кривошеин.