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; t=1680760829; x=1683352829; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=hzZgr8eGEJCC+TJRAZACwmz4BCO9PjCxvXvOLiOYIdw=; b=dQoDJ6Bpc6Zox8AkNXNX8Z5TGqewZDjug+Xin8UyYcdugXyj7zPA9Wr1bOeo7k4O+1 BEV5J+J1qiXtjkfIfG0daqlEjdpNoUalipvTgI/Dp59SciC51NUDjg3uiHwjAGpxPxp+ 2CH0YuxjBNbP3ExyfK9HrRUqo454Vo+ULTLGDlqGKMBzQ7N7bA9A6Ag6qwrID6WSlbim SVjUg0Bq35FKqm9bJo3oyjRdZI1+eKZxZhCmmFPn/EfkZnPw7SCPE0K5Na4JBLVjBSae HdQYzbmalEFHv+KBOUUxhwB/BjMQC0O8m34VqceGWNT0X49wP9+gE2OW9LP7ZGrfqHEO GbCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680760829; x=1683352829; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hzZgr8eGEJCC+TJRAZACwmz4BCO9PjCxvXvOLiOYIdw=; b=JkdjHyCtSEqNdr/csyGKhHr7zIIjIMQVy6AN94m3hD18Ao31w3CoDa2ze/+g4uSyjh R+DF/ty6GF0OihMvWyJwjQvW8ejZD2JoQ29IgVq1HeQHJEt2cpruYdKgVSPVZJGrDy/B V2S47BLviI1uEhoJ/k8InFhpDTjVeMIB/LJHLC8gZiVKarIxKSQ06xUXWawmCYgXMh/J FEKBpZRcEAjGK/b6voELd10fuHZGvaSMUb/Cp3eZWOfzgZUkPwyBAlyOMR286ij29vxq GaqBtj98LQiw6LmB+TNXK1t6aNGcSER7VgMGzjAUeSWmVIR8PrG+qRb6SU5zPgL/Pd/7 kOdA== X-Gm-Message-State: AAQBX9eByjNC6wgzmXJUGLSGsd5N+L0pn1MvcSbo1Nsek/HSTm3z3i9V SGIDLHlbGoPHC8HNIpzdq8WDA0+4FGw= X-Google-Smtp-Source: AKy350ZAyNWppmPLl/mfVSE59bgbBZ1f0RZgTTdLnsJSyv6Zz4h0GZlZslUE4ESSkeTiqRXHr/A7vw== X-Received: by 2002:a05:6870:9729:b0:17a:fd25:470e with SMTP id n41-20020a056870972900b0017afd25470emr3155364oaq.7.1680760829110; Wed, 05 Apr 2023 23:00:29 -0700 (PDT) Message-ID: Date: Thu, 6 Apr 2023 09:00:27 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.9.0 To: make-initrd@lists.altlinux.org References: <7d19288d-96a9-186c-768d-95a09b02c225@basealt.ru> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: <7d19288d-96a9-186c-768d-95a09b02c225@basealt.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] =?utf-8?b?cG9sbGQg0Lgg0L/RgNC+0LLQtdGA0LrQsCDQvdCw?= =?utf-8?b?0LvQuNGH0LjRjyAvcm9vdC9zYmluL2luaXQ=?= 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, 06 Apr 2023 06:00:33 -0000 Archived-At: List-Archive: Добрый день! On 4/6/23 04:28, Антон Мидюков wrote: > Здравствуйте > > Предыстория: https://bugzilla.altlinux.org/44111 > > Заглавный вопрос: "в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется?" На p10 с пропагатором и более старым ядром не проявляется, так что все под подозрением, кроме этих двоих.)) > Мне кажется, ответ найден: "При распараллеливании процесса монтирования корня (из сквоша, как минимум) на медленном сетевом соединении или достаточно медленном локальном накопителе". > Сейчас проблема стала хорошо воспроизводиться на ядре 6.2 при подключении по nfs или загрузке через ventoy и монтировании сквоша (без предварительной загрузки сквоша в память) на многоядерных процессорах. > Если ядро одно, то проблемы нет (проверено в виртуалке). > В ядре включили алгоритм монтирования оверлея CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU, и это проблему усугубило. > Но проблему крайне редко можно было поймать и раньше. А на p10 с пропагатором удавалось воспроизвести? Мне ни разу не удалось, хотя концовка с монтированием оверлея на скриптах у них схожа. > Отсюда выводы: > 1. Факт монтирования корня недостаточное условие, существует переходный процесс монтирования Насколько я понимаю, у каждой группы процессов может быть собственное пространство имён монтирования, но описываемое поведение говорит о том, что polld и chaind находятся в разных пространствах имён и ещё что-то заставляет перемещать структуры в ядре от одной из групп к другой. В общем странно и невероятно, потому что по идее, если пространства разные, они изолированы, а если одинаковые, все процессы должны увидеть изменения мгновенно. Тем не менее, мы наблюдаем именно такое поведение, описанное Антоном. Весьма похоже на ядерный рейс, поскольку на начальном этапе загрузка работой сильная и "мгновенности" не случается. > 2. Обнаружение /sbin/init также не является достаточным условием, что можно продолжать загрузку, переходный процесс может оказаться длинным Получается, грубо говоря, что мы не знаем, в скольких тредах выполнения (снаружи bootchain) должна пройти синхронизация и чего именно ожидать. В bootchain команда mount завершилась успешно, ядро смонтировало устройства. Но polld почему-то об этом ничего не знает. По идее polld должен начинать проверку только после выхода из bootchain на вызове telinit 2, если эта проверка на нём. > Гипотеза о переходном процессе основана на сопоставлении двух логов chaind.log и polld.log > Ошибка об отсутствии /sbin/init была выдана на 1 секунду раньше, чем было завершено монтирование оверлея (оно занимало две секунды). Похоже на какой-то глюк с ходом часов (хотя monotonic timestamp используется) или особенность работы telinit 2. У меня нет идей. > И другая проблема, вытекающая из этих: > bootchain после монтирования /sbin/init совершает ещё действия, поэтому нужно дождаться его выполнения. В нём это делать бесполезно, там всё хорошо будет. > В случае bootchain было бы надёжным запускать polld только тогда, когда он завершил свою работу. > Такое в принципе возможно? Тут большой вопрос, кто кого запускает. Не знаю назначение polld, но мне кажется именно его сообщения мы видим на /dev/console о запуске и завершении служб. Я считаю, что несмотря на пошаговую загрузку в bootchain, мы не можем останавливать event-driven механизм. -- WBR, Leonid Krivoshein.