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=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780309894; bh=KL3iGmLKoPLvcMB91C/i7Xj2tzHKha4KaEEY3qulfgQ=; h=Date:From:To:Subject:References:In-Reply-To; b=LHjHFjAPxrh9FgfAYeUtRz9PAWDd2V48p39GDL59AC6cUYR045C9foYyaDuhLcuWM OiWmWYiRzaPVlU/oCvMqZBm/tWPYGK5wq3fVZO98/O2cEjTWhNjEiyvKCOX2faHQNR 0Y3fHZOScnEUuWHzCuYDErz+CJyW4W+Q0CxmlYB5/k+Sga+OoCwGCrKnUZPn4Boz0j fKCc4vig0RPp6o+Y4DIE58EdGDK651FRocB+Mq9XacfiNjIevFJ/hQYazLs0iZzVdU ro5xm8mmGy5MqlF0aNMrMja/s8zLU8bPSal2LmeQ6kjMApLa5PBY3ejXQaMuWOxGSX nG9FKjhqxc21A== Date: Mon, 1 Jun 2026 12:31:29 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <7abadb27-fa4e-4a3b-940d-1688f0b067ca@altlinux.org> <84eb4e6d-4952-44fb-ad2b-d696b563a5eb@altlinux.org> <8c4f166a-c736-46a2-853e-253a3284539b@altlinux.org> 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] =?utf-8?b?0JfQsNC80LXQvdCwIC92YXIvcnVuINC4IC92YXIv?= =?utf-8?b?bG9jayDQvdCwINGB0LjQvNC70LjQvdC60LgsINGD0LrQsNC30YvQstCw0Y4=?= =?utf-8?b?0YjQuNC1INC90LAgL3J1biDQuCAvcnVuL2xvY2sg0L3QsCDRgdGC0LDQtNC4?= =?utf-8?b?0LggaW5pdHJk?= 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: Mon, 01 Jun 2026 10:31:38 -0000 Archived-At: List-Archive: On Mon, Jun 01, 2026 at 01:04:05PM +0300, Anton Midyukov wrote: > 01.06.2026 12:01, Alexey Gladkov пишет: > > On Mon, Jun 01, 2026 at 11:18:59AM +0300, Anton Midyukov wrote: > >>>>>>>> Доброго времени суток > >>>>>>>> > >>>>>>>> Необходимость замены /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock > >>>>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке. > >>>>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась. > >>>>>>>> > >>>>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd. > >>>>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе. > >>>>>>>> А также потребуется монтировать систему на запись. > >>>>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock > >>>>>>>> не являются симлинками. > >>>>>>>> Хотелось бы узнать, насколько это хорошая идея. > >>>>>>> > >>>>>>> Технически это возможно. В момент initramfs можно добавить > >>>>>>> > >>>>>>> MOUNTPOINTS += /var > >>>>>>> > >>>>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся > >>>>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT, > >>>>>>> что сделало бы миграцию. > >>>>>>> > >>>>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время > >>>>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова > >>>>>>> скрипта определённого имени из рута системы перед запуском INIT. > >>>>>>> > >>>> > >>>> А почему скрипт не помещать в initrd? Чтобы была универсальной? > >>> > >>> Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про > >>> необходимость дополнительных действий при создании initrd). У меня идея > >>> была в том, что бы любой initrd мог выполнить манипуляции с системой, > >>> пользуясь либо утилитами из initrd, либо из системы. > >>> > >>>> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и > >>>> какой-то ещё переменной, которая укажет путь до скрипта. > >>>> И тогда мы получаем простой способ делать с системой разное. Мне нравится. > >>> > >>> У нас есть: > >>> > >>> features/runtime/data/etc/rc.d/rc.sysexec > >>> > >>> его можно расширить запуском дополнительных скриптов. Нужно лишь придумать > >>> какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать > >>> какой-нибудь /lib/sysexec.sh ? > >>> > >>> Тогда вся обновлялка твоя будет: > >>> > >>> MOUNTPOINTS += /var > >>> PUT_FILES += /lib/sysexec.sh > >>> > >> > >> Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами, > >> в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами. > >> (хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении) > >> То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC. > >> > > > > Раз речь уже идёт о %postinstall, то, возможно, стоит сделать > > /lib/initramfs-upgrade.d и класть его в initrd. Тогда разные пакеты > > могут класть туда скрипты параллельно, а триггер сгенерирует финальный > > initrd. > > > > Тогда возникает, видимо, проблемка, что до удаления пакета скрипт будет попадать в initrd постоянно. > Но можно его не пакетить, а создавать в %postinstall туда, и при успешном выполнении себя оттуда удалять. > Но как быть с MOUNTPOINTS += /var? Добавлять в /etc/initrd.mk, а потом оттуда убирать после успешного выполнения скрипта? > В целом, такого тогда достаточно будет. Так. Сформулируй ещё раз по пунктам, что тебе хочется иметь. Потому что изначально, когда я предлагал /lib/sysexec.sh то думал, что инсталлер (ты упоминал установку) будет делать: make-initrd MOUNTPOINTS+=/var PUT_FILES+=/lib/sysexec.sh то есть добавлять эти параметры один раз без конфига или с отдельным конфигом. Тогда бы после миграции и перегенерации initrd этих файлов там не было бы. Если же мы говорим про опакечивание и %postinstall, то тут уже несколько другое дело. С `MOUNTPOINTS += /var` просится какая-то инфраструктура с кусками конфига и скриптами, но мне очень не хочется раздувать эту идею. Это может превратиться в целый фреймворк для обновлений с генерацией конфига и проверками применённости состояния. -- Rgrds, legion